WebAssembly is an experimental-ish technology that allows developers to build really fast web applications that run in your browser.
You can write whatever programming language you want on your server: but only JavaScript runs in the browser
JavaScript is great, but it can have performance limitations; other languages are usually faster when used correctly
WebAssembly lets developers write code in faster languages – like C++ and Rust – that still runs in your browser
It’s very early, but there’s excitement around it for performance intensive apps like video editing, gaming, CAD, and AR/VR
Chances are that few, if any of the apps that you use daily actually use WebAssembly, which makes finding examples a bit difficult. But there’s a ton of excitement around it in the ecosystem, and a growing consensus seems to be that it’s going to be a big part of the web stack over the next decade. So read on!
Hey there loyal subscribers. I hope you’ve enjoyed explaining technical concepts to your family members at dinner this Thanksgiving. It is a truly auspicious time of year, because for the next week you can get a paid Technically subscription for 20% off for 12 months!
Just use the code GETTECHNICAL when you check out:
Paid subscribers get a lot of exclusive, in depth content that helps them get more technical and work with engineers. A few highlights:
In Part I of our ‘What is low-code’ post, we talked about how low-code
simplifies building software and makes it more accessible to non-technical builders.
If it’s all sounding a little nebulous, in
this part, we’re going to talk more concretely about who low-code is aimed towards, some of the ways in which you can use low-code, and how
some different platforms approach this kind of development.
So, who is low-code really for?
Well, it sort of depends on the tool. As we’ve said before, low-code is something of a
spectrum, and there’s a bit of something for everyone.
There’s the ‘no-code’ community, which is typically made up of
completely non-software devs, or at least non-coders. For web apps this is platforms like Bubble or Softr. Then you have low-code for people who can use a bit of JavaScript (for instance) to
customize functionality somewhat, but not more than that. And then you have developer tools like Retool, which are made for proper engineers, and generally look quite scary to anyone who
hasn’t made an app before.
This is a reasonably arbitrary illustration, but it gives you an
idea
Low-code means that SMBs (small to medium businesses) and start-ups can get basic products out the
door faster – software engineers are incredibly expensive, and custom coding can take a really long time. Lowering the bar for software
development skills has generally made the software space more accessible for all kinds of people.
Nevertheless, we’re even seeing
enterprise companies using low-code to speed up their software development cycles, so the use cases are not just limited to less-technical
teams.
Examples of how people use low-code
Let’s take a look at some concrete examples of low-code products in
action.
1) Websites
The most commonly used and well known low-code tools are website builders, like Wix, Squarespace, or Webflow.
Using these platforms you can create professional-looking websites without needing a line of code. But, a lot of them are also extensible with
code if you want.
Wix and Squarespace are so simple to use that complete beginners can give them a go. Squarespace operates with
rigid templates, which create quite basic, cookie-cutter websites, but they get the job done quickly. Wix allows you to drag-and-drop a bit
more freely, and use different components to add more functionality.
Nevertheless, they are both really quite limited. You can add
some lines of code here and there to help customize a bit more, but the bounds of key elements (such as reactive sizing depending on screen
dimensions) are determined by the product. The “right tool for the right job” concept rears its head here: if you want to build a beautiful,
custom, slick-looking website, you’re going to struggle with these tools.
Editing styles in the Squarespace
editor
Since Wix offers a bit more flexibility with building, it has had to sacrifice performance to an extent,
so pages may load slower than you like (at least in my experience). It’s important to fully research the product's capabilities before
starting to build, especially if you are looking to scale your project.
For simple websites, like portfolios or sites for
brick-and-mortar businesses that don’t need to integrate complex elements like online shopping or a catalog, Squarespace and Wix are great
options.
Webflow is an option that is on the ‘more code’ side of low-code in website builders, based more closely on traditional coding
practices. While you won’t necessarily be writing lots of lines of code, you need to know what a ‘div’ is and how a website needs to be
constructed on a technical level.
The Webflow editor
There’s a pretty steep
learning curve to Webflow1, but you can get some really great results - especially if you understand the principles of coding a website from scratch
(and are even capable of doing so), but are just looking for a quicker option.
Finally, depending on how you build, Wordpress can
be as low-code as you like. You can code an entire site and host and manage it on Wordpress, or you can use plug-ins and builders to create
sites without too much code. Like Webflow, Wordpress requires a more technical understanding when building, though you may not need to write
any code.
The Wordpress editor
2) Customer-facing
web and mobile apps
Some low-code platforms boast the ability to create your core, customer-facing products on web or mobile. Bubble is a popular no-code solution for web apps that can integrate with your existing backends to build web
applications such as marketplaces, social networks, and e-commerce sites.
You can create some pretty attractive apps, but you are
limited by the ability to include your own code. It’s also hosted on their cloud, which means that you have limited control over the hosting
environment and may experience downtime or performance issues if Bubble experiences technical problems. It can be a great option for an MVP to
test out on your users, especially for rookie builders with big ideas.
The Bubble editor
Glide is a no-code platform that allows you to build apps specifically for mobile devices. Glide's
intuitive interface and affordable pricing make it a great option for businesses and individuals who want to create mobile apps quickly and
easily. Nevertheless, as with Bubble, customization and functionality options are limited by their no-code interface, as is the branding and
styling, which could be an issue for customer-facing products.
The Glide editor
Outsystems is another option on the more-code side of the spectrum, which allows users to build apps
for web and mobile, both internally and for external use. The platform abstracts many of the coding elements of building into a proprietary,
visual language, and is slightly less intuitive than Bubble and Glide, though more customizable. OutSystems is one of the OGs of low-code
development and is therefore a firm favorite for many companies having been around for a while. There’s certainly a learning curve, but the
app offers much more flexibility with the ability to extend with code.
The Outsystems editor
In reality, it’s a
little optimistic to think you can build an immaculate application with a high level of functionality using just a low-code tool. You’ll
certainly need to make some allowances for your platform’s limitations, but low-code builders do allow for a quick MVP or basic product, as
well as giving non-developers the chance to build something without an engineer. Ultimately, it’s unlikely that any of the applications you
use on a day-to-day basis are built with low-code, but give it a few more years and that might change.
3) Automations and scheduled
jobs: Slack pings, Gsheet integrations, etc
Scheduled jobs and automations are a key part of tech stacks - they keep things ticking
away in the background and make sure everything is moving smoothly and automatically.
Some automations that might sound
familiar:
When a user signs up to your mailing list this might automatically trigger to send them a welcome email with a
discount
When a customer buys a product, the order is automatically added to an order database and the details are sent to the
operations team to package the delivery
A mailing label might be automatically printed and an email confirmation sent to the
customer when they purchase and when the package is sent for delivery
Automations are processes that require as little human
interaction as possible.
📌 cron jobs are scheduled processes that an operating system runs out at
certain times you define. This might include backing up your emails to your servers every night or pushing data between different databases at
scheduled times.
Your core processes – the ones that you can’t afford to go wrong – are probably best left to the
experts, but what if you want to receive a Slack notification whenever someone fills out an online form? Or every Monday you’d like the
management team to receive a summary of all the sales that the team has completed the previous week? These are great use cases for low-code
automation tools and don’t need a developer to set up.
Tools like Make and Zapier, make simple connections between apps like Google Sheets, Slack, Asana, and email. You can set up
triggers and workflows to start based on them, all without writing any code.
Gmail related integrations from
Zapier
Internal tool builders like Retool offer more technical versions of these automation builders. You’ll
need to know some code (JavaScript or Python in this case), but the task is hosted on their servers, and the connections are maintained by
their platform, making them really useful for those mid-priority automations that are a pain to maintain.
They also offer the ability to build apps for internal use, so you can build these
automations and internal tools all in one place, cue…
4) Internal tools: CRMs, admin panels etc
Internal tools are apps built by your teammates, for your
teammates – anything non-user facing. It’s very common for companies to buy software for internal use where possible, but sometimes it’s
expensive or just doesn’t do what you need it to do.
Since internal tools are our bread and butter at Bold Tech, this is a great area for us to show some of the nitty-gritty of low-code
builders.
Let’s start on the no-code side of the spectrum. If you just need a simple CRM with some custom reports, you could use
something like Airtable to create a spreadsheet-like database, but also easily add forms, integrations to
Slack etc, and some data analytics (honestly, Google Sheets can also be a good option).
An Airtable base
It’s super quick and
easy to set up, but certainly comes with its limitations. What you see here is what you get, a spreadsheet-like interface with customization
options for data input and data types. You can build a little on top of Airtable using their interface builder, but it’s quite a limited
option.
Moving up the low-code spectrum, let’s take a more complex example, where developers might get involved. Let’s say you
need a large database of all of your customer order history and need to issue refunds. To start, you can actually set up your database on a
low-code backend (you can use Airtable or Google Sheets). Though not strictly low-code, one of our favorite databases is Supabase, which is a cloud-hosted SQL solution with all the bells and whistles of a Postgres database, but a
simple, intuitive UI to set it up.
Now you need a frontend. You can use a platform like Retool to spin up a
basic UI to interact with a database in a non-technical way, that changes the status of an order, and you can even integrate the Stripe API to issue the refund directly. If you are an experienced engineer, you can build something
basic like this in just minutes (with an extra few to get the hang of the platform), and you can use code to extend your app and create
something much more complex if you allow for a couple more hours.
A customer support tool in Retool
While a
non-technical builder could certainly produce something on Retool, the beauty is really in its technicality: engineers themselves can skip the
repetitive stuff, but still use their coding knowledge to make highly complex, highly customized applications that do exactly what they need
them to do. Minus the weeks and complexity of a custom build - the kind we broke down in Part I.
Other low-code builders (that are
on the developer tool side of the equation) include Budibase and Appsmith, to name a few. We specialize in building internal tools on low-code platforms, and Retool is
definitely our favorite in terms of extensibility, performance and speed of building.
This ‘developer tool’ approach is a relatively new
sector of the ‘low-code’ spectrum, and even a new mindset, since it really requires engineers to separate their prejudice against low-code
tools (usually based on the blocks they hit with building functionality) and embrace the drag-and-drop.
Ultimately,
low-code/developer tools aren’t perfect nor widely accepted, but as these platforms work to iron out their flaws and work to catch up with the
customizability, performance and portability of traditionally custom-coded apps, more developers will get on board and the platforms will
improve even more.
Passkeys are a way to securely sign into the apps and websites you love without needing to remember a password or username.
Passwords have been around since the 60’s, and are both not-that-secure and annoying to remember and manage
Passkeys – based on public/private cryptography – let you log in instantly and securely without having to manage usernames and passwords
Passkeys are picking up momentum: companies like Adobe, Kayak, and PayPal support logging in with them
As the developer of an app or site though, it’s tedious and difficult to implement Passkeys yourself across browsers and devices
The Passkey technology has been around for a while, but 2023 has been a critically important year, thanks to some important releases from Google and Apple. So read on!
Hello dear paid subscribers, and welcome to the sixth issue of Ask Technically. You know the drill — you ask questions about software, hardware, and everything in between, and I’ll tackle a few every issue to make sure everyone gets a quality and thorough answer.
If you missed the last paid post about Heroku, you can check it out here.
If you have any questions of your own, just reply to this email or send them to justin@technically.dev.
This is a guest post from Leonardo at ScraperAPI. If you’re looking for an enterprise-level data collection tool without the big price tag, check them out.
The TL;DR
Web scraping is a technique to automatically collect data from websites (e.g., text, images, product prices, stock data, etc.) through code.
Web Scraping comes down to four steps: picking a URL, accessing the data programmatically (through code), extracting the needed information, and storing the data for later use or analysis
Many websites use anti-scraping mechanisms to block bots from accessing their data, like organizing and naming website elements in confusing ways
Most engineers use open source libraries to scrape websites, but simpler beginner-friendly tools exist to help non-technical folks gather the data they need
When you think of software engineering, you envision developers working hard on customer facing features. But a surprising amount of developer time is actually spent on making apps usable for large companies, a group that has a rigorous and sometimes oddly specific list of requirements. If you’ve heard of SSO, RBAC, or SIEM, you’re in the right place – this post is going to break down how developers make apps enterprise-ready and why a disproportionate amount of time is spent on these seemingly niche features.
Developing applications for larger customers
You wouldn’t necessarily think that you’d build your app significantly differently depending on the size of the company you’re trying to sell it to – but then you’d be wrong. Enterprises – and increasingly common today, just large startups – have specific, rigid requirements for the applications they buy and commit to using. The larger the company, the more customers they have, and the more is at stake: they command higher standards of security, support, and ease of integration from their vendors.
When I hear enterprise sales, my gut reaction is to think of IBM reps wearing Rolexes on a golf course selling multi-year contracts for tens of millions of dollars.
It’s now many months since I wrote about ChatGPT, and there’s even more going on in AI. OpenAI definitely took the world by storm, but open source models – and even closed source competitors like Midjourney – are catching up. Theoretical interest aside, this matters because these models can actually be useful to you at your job: generating marketing copy, cover images, doing research, writing your blog posts for you, you name it.
In the post about why ML models seem to be getting so much better, I wrote something I think is important:
Over the past couple of years, models have gone from private, code first, and inaccessible to widely available to the public.
If you look at models that have made it into the public discourse recently, like DALL-E or Stable Diffusion, they share a unique quality: whoever built the model (or their friends) also built an interface to the model. Using ChatGPT is as simple as typing a prompt into OpenAI’s website; generating a photo with DALL-E is too. It’s for everyone! And that is very weird.
An ORM is software that lets developers interact with their database in their programming language of choice – instead of SQL.
Most apps are built on relational databases like MySQL or PostgreSQL, which you talk to using SQL
SQL is great, but can get complicated and unwieldy when building web apps
ORMs translateSQL into languages developers are building in, like JavaScript or Python
Popular ORMs include Django, SQLAlchemy, Sequelize, and ActiveRecord
Almost every developer uses an ORM of some sort; and a new wave of databases are popping up with ORMs built in. You might not have heard of them, but they’re an under appreciated part of the backend stack.
OpenAI researches and builds Machine Learning models, and sells access to them.
Building ML models yourself to use day in and day out is really hard for companies without specialized expertise
For years, big companies (Google, AWS, etc.), and smaller startups too, have built businesses on selling access to their home grown models
OpenAI does the same: researches, builds, and sells access to powerful ML models like GPT and DALL-E
The company is a bit strange: they’re a combination of a non-profit and for-profit corporation
OpenAI has obviously been all over the news over the past year, and is probably one of the most important companies in the world right now – so let’s dig in.
This is a guest post from Sophie Becker, who leads content at BoldTech, a company I used to work with that helps teams build internal tools.
“Low-code” has been something of a buzzword in the tech world over the last few years - but what does it really mean? And is it really changing the face of software engineering as much as the marketing teams at these companies say it is?
This is a post from Danny Levy, a writer, a friend, and a former colleague from my time at DigitalOcean. Danny doesn’t have an engineering background but has worked for years at getting more technical.
We’ve all seen it before, the ominous black screen where engineers pitter-patter unintelligible alpha numeric globs of code like witches brewing a stew of newt’s tails and toad’s eyes. For business people who have bravely taken steps towards becoming more technical, we might find ourselves face to face with these dreadful black screens where a giant leap of faith or a supernatural event must take place to help us do something with it. We may be afraid, but it behooves us to understand it.
The CLI, or Command Line Interface, is simply a place to write commands that your computer follows, and that can make you a lot more productive. You can use the CLI to perform a wide range of tasks, such as managing files and folders, installing software, running scripts, and communicating with other computers on a network, and, yes, even writing code.
🚨 Confusion Alert 🚨
CLI technically refers to anything that you interact with in the Terminal. You’ll hear developers refer to the Terminal as the CLI, but you also may see software that you use may offer a CLI. What that means is just that they have an interface you can use in the Terminal to run specific commands and do things with it, like Heroku’s.
Vercel builds a frontend-as-a-service product – they make it easy for engineers to deploy and run the user facing parts of their applications.
Applications have two parts: the frontend and the backend (have I mentioned this before???)
The frontend is usually deployed with the backend on a single server (or set of servers), which means infrastructure to set up and manage
Vercel lets teams deploy their frontend stupidly easily, separately from their backend
Deploying with Vercel gives you nice features like deploy previews, functions as a service, analytics, and more
Beyond just the frontend, Vercel has been adding cloud-like features like storage and databases
While how you deployed your frontend was nobody’s business a few years ago, tools like Vercel are now (maybe?) the standard for how teams get their frontends up on the web. The Technically website is even built with Vercel!
Your favorite paid subscriber-only neighborhood advice column is back, baby. On the docket today: explaining what a runtime is, looking at software libraries and how they’re used, and explaining gRPC, which is actually an infinite acronym (fucking engineers, man).
If you have any burning questions of your own, just reply to this email (or if you’re reading this on web, email me).
Tina asks…one item I'd love an article on is Runtime - what is it exactly and what does it mean?
Here at Technically Inc., we pride ourselves on explaining each part of the software stack in an accessible and friendly way. But every now and then, it’s important to think about how these pieces fit together, and how engineers use them. This week, we’re going to walk through exactly what happens when an engineer builds something new, from ideation to new code making its way to users.
If you’re:
At a tech company, wondering why your developers told you a small feature would take 3 months to build
A financier trying to understand what CI/CD is and where it fits into the stack
Hello dear paid subscribers. There has been a lot going on in AI over the past few weeks, all difficult to understand if you’re not a Machine Learning engineer. This (short) post will hopefully make everything easier to digest.
OpenAI released a new version of GPT-3
GPT-3 initially came out in July 2020 to a good degree of fanfare. And since then, OpenAI (the parent company that’s making this stuff) has been releasing interesting interfaces on top of it, the most popular of which has been ChatGPT. ChatGPT did not write this article.
There are at least300+ databases out there, and they all do something slightly different. From Postgres to Elastic to Cassandra, there are virtually unlimited ways to store and query your data; and most companies will use several of them in tandem. So when your engineering lead tells you that the project is going to take an extra two weeks because they need to create a new data store for log analysis, what exactly is going on?
Allow me, for a moment, a metaphor.
I’ve gotten into baking recently, and choosing which type of flour to use has been an unexpectedly important piece of the equation. Each flour type has a different protein content; more protein means more gluten, which (generally) means a thicker bread. For pastries you use flour that has less protein, since you want them to be light and flaky. Flour for pizza dough should have more protein since you want it to be chewy. And then you’ve got all purpose flour, which is sort of in the middle, and you can use it for everything, although the results won’t be as good as if you picked the perfect flour for the job.
Heroku, founded in 2007, was (and is) one of the first cloud platforms as a service. Heroku makes it easy to build and run applications in the cloud without the need to set up or manage your own infrastructure.
Though easier than in the past, setting up your application today requires a good deal of configuration and maintenance
Standard infrastructure as a service offerings (AWS EC2, etc.) have lots and lots of knobs and buttons to nail down (flexibility comes at a cost!)
Heroku (and PaaS like it) greatly simplify everything for developers and makes it easy to deploy and run apps
Key Heroku features: auto deploy from GitHub, straightforward CLI, simple pricing, plugin ecosystem
In many ways, Heroku was ahead of its time: they were acquired by Salesforce in 2010 (12 years ago!), and since then have mostly gone downhill. It’s hard to find a product as beloved by developers as Heroku (and as tragic), so it’s worth understanding what they do.
This is a deep dive post, exclusively for paid subscribers. The last one covered frontends and backends.
Large Language Models (LLMs) like ChatGPT, the new “Sydney” mode in Bing (which still exists apparently), and Google’s Bard have completely taken over the news cycles. I’ll leave the speculation on whose jobs these are going to steal for other publications; this post is going to dive into how these models actually work, from where they get their data to the math (well, the basics you need to know) that allows them to generate such weirdly “real” text.
💡Interested in more AI and Machine Learning related content like this? Or would you rather me stick to traditional software engineering? Let me know in the comments.
A blockchain is a digital ledger. Blockchains as a concept have been around for a while, but they’ve recently become popular because of the cryptocurrency boom (Bitcoin anyone?).
A blockchain is just another way to store data. As with any other technology, there are trade-offs when using it
Blockchains record transactions, which are asset transfers between parties
The blockchains we hear about are decentralized, which means no single entity controls them
Decentralized blockchains are the technology underlying popular cryptocurrencies like Bitcoin and Ether
The Modern Data Stack™ (MDS) is a new-ish set of tools that data teams are using to collect, transform, explore, and make use of their company’s data.
Although the data team as we know it is a relatively modern concept, there’s a rich history of data-related software and stacks
Older data stacks were run mostly on open source data stores, hosted on premises, and required tons of configuration and maintenance
The modern data stack focuses on speed and simplicity: serverless cloud data warehouses, easy cloud-based SaaS tools for modeling, and native integrations with other tools
The MDS has become a bit of a meme in the data community for growing into an overused marketing gimmick
In this post we’ll cut through the marketing noise and focus on what’s actually important about the MDS, how it helps data teams be more effective, and what specific tools people are using to do that.
Hey everyone, and happy new year. I’m excited to kick off the year with a bang and introduce Technically Learning Tracks, the best way to get from 0 to decently technical in no time at all. In short, learning tracks take all of the 50+ breakdowns we’ve published and organize them into digestible, straightforward stories. If you want to get more technical but you’re unsure where to start, learning tracks are for you. You can check out the first two tracks here.
Hello dear paid subscribers, and welcome to the fourth issue of Ask Technically. You know the drill — you ask questions about software, hardware, and everything in between, and I’ll tackle 2-3 every issue to make sure everyone gets a quality and thorough answer.
If you missed the last paid post about production databases, you can check it out here.
This week’s questions are all API related, a theme that I hope you enjoy as you settle in for a reading journey filled with drama, intrigue, and acronyms.
If you have any questions of your own, just reply to this email or send them to justin@technically.dev.
2022 was a wacky year, but a busy one for Technically. We did:
21,000 new free subscribers (thank you!)
800 new paid subscribers (thank you more!)
1M+ post views
24 new posts and 2 new content formats
When I started the newsletter 3 years ago in the airport in Tokyo on a whim, I did not ever imagine it getting here. So thank you to all of you for supporting my work: subscribing, reading, leaving comments, getting outraged, and all of the other little ways that this community has participated in 2022.
I’ve got so much more exciting stuff planned for next year, and I’m going to give you a sneak peek. But first: let’s look at the top posts that you’ve read this year.
Hightouch helps you sync your customer data from your warehouse into the tools your business teams rely on every day. No custom code, no APIs, just SQL. In a few clicks and you’ve got the data you need in Salesforce, Hubspot, etc. Check out their guide to Reverse ETL, or book a demo here.
When I graduated with a Data Science degree in 2017, AI was kind of like a funny toy, and mostly something researchers (read: not me) spent their time on. Getting a half decent result from an ML model involved a bunch of code, several failed attempts at training, and then the inevitable abdication and surrender.
Snowflake is a cloud data warehouse. Data teams use it to store and query their analytical data.
Refresher: what’s a Data Warehouse?
A data warehouse is a specially designed database that holds analytical data. It’s built to handle long, complicated queries written by data scientists, analysts, and machine learning engineers.
If you’re iffy on what data warehouses do, now would be a good time to read the original post here. It covers:
Hey there loyal subscribers. I hope you’ve enjoyed explaining technical concepts to your family members at dinner this Thanksgiving. It is a truly auspicious time of year, because for the next week you can get a paid Technically subscription for 20% off for 12 months!
Technically works with companies looking for exposure to ambitious, technically-adjacent leaders across tech and finance. Publicly traded companies and startups alike have gotten their message out through a Technically sponsorship. Reach out for more details.
STAT SHEET
40K+ Subscribers – Non-technical working professionals. Think PMs, Marketers, Customer Support, Designers, etc.
45-50% Open Rates – For paid subscriber posts, open rates are upwards of 60%+. Sponsorship CTRs as high as 2%+.
Biweekly Posts – Technically publishes to the entire list once per month, and to the paid list a second time every month.
Hello my dear subscribers. Today I’m excited to introduce the Technically Job Board, a list of jobs for the technically adjacent. These are roles curated by me where the technical chops you’ve been picking up from the newsletter will help you succeed and get rich.
Tokenization (nothing to do with NFTs) is one of the ways that backends protect sensitive information, like credit cards or social security numbers.
Sensitive information is important in many of the apps you use every day, but it’s dangerous to store and use unprotected
Tokenization replaces sensitive data with placeholders that point back to it
To tokenize your data, you’ll need a system/platform to create and manage tokens
Tokenization works in step with encryption, but in theory may be more secure
Security is always part and parcel of building a good application. But as more data privacy regulation seems to be on the way, developers are thinking more about how to secure their application (and user) data.
(The New York Times recentlyreleased an articlecritiquing LinkedIn for its A/B testing and experimentation practices. This will be shorter form post that just explains what’s going on with the technical side, for those curious.)
Join 30K+ other people getting more technical:
(if you get this reference, email me for a discount code)
Welcome to a Technically dispatch, where we quickly explain major events in the news that relate to software and technical things. The NYT released an “investigation” tearing down LinkedIn for their A/B testing this week, and everyone on Twitter has been talking about it. LinkedIn wasn’t shy about this, and didn’t try to hide it: they literally published an academic paper analyzing the results this month.
Most of the stuff we’ve done here at Technically has focused on building applications for users: things like Twitter, Gmail, and Salesforce that people like us use most days. But a lot of code – potentially up to 30% of it – gets written for internal use cases, i.e. apps built by your teammates for your teammates. Those use cases span from basic tools like admin panels for updating your user information all the way to complex build tools for packaging your application before deployment.
Chances are you’ve probably used at least one of these tools in your day to day. So what different types of internal tools are there? And how do they get built?
Join 30K people getting more technical (join usssssssss)
Hello dear paid subscribers, and welcome to the third issue of Ask Technically. A while back, I asked you all for burning questions about software, hardware, and everything in between and the response was overwhelming! I’ve got 50+ questions to work my way through, so we’ll tackle 2-3 every issue to make sure everyone gets a quality and thorough answer.
Recall that Ask Technically of course does not replace the exclusive paid content (deep dives, company breakdowns) that you signed up for; it’s just a new format I’m adding into the mix to make sure you’re getting even more out of your subscription. If you missed the last paid post about frontends and backends, you can check it out here.
If you have any questions of your own, just reply to this email or send them to justin@technically.dev.
Caching is the process of storing things (webpages, images, etc.) closer to whoever is requesting them so that those things load faster.
When you load a web page or an app, you’re requesting files from a server – and that server can be physically far away
Developers will cache content on servers closer to you so that those web pages and apps will load faster
Because web page and apps change all the time, you can set a timer on cached content to force it to expire
Specialized server networks called CDNs let you cache content easily across the globe
Almost every website you use is being cached in some format or another, and it’s an important part of how modern web apps are built (also, the kind of thing they don’t teach you in CS degrees).
“The Details” is a paid-subscriber-only series that dives deep into technical topics, surfacing only the details you need to know. The last “The Details” post was about SQL and NoSQL production databases. Have an idea for a “The Details” topic? Just reply to this (if it’s in your inbox) or send it to justin@technically.dev.
It seems like I’m referencing the difference between a frontend and a backend in almost every single Technically post, so I figured it made sense to spend some time diving into what those really are, and most importantly, give you a real example of what goes into a frontend vs. what goes into a backend in a real life application.
This distinction – so important! If I’ve done my job correctly, you’ll begin to see all software you use as frontends and backends of varying shapes and sizes. So without further ado…
## Frontends and backends: the restaurants of code
One of the defining problems of our time, if I may say so myself, is technical literacy: technology is eating up more and more of what we do, and we seem to be getting worse at understanding it. Maybe you work at a tech company and want to understand what your engineers are talking about; or you could be employed at a hedge fund, trying to figure out what the newest infrastructure company going public actually does. No matter who you are, being a non-engineer in an engineer’s world can be very frustrating. And it’s hard to find a way out.
So how do you get more technical? What should you even be learning about? This post is going to walk through what it means to really get more technical, what worked for me, and a few suggestions as to what could work for you.
What does technical literacy mean? The function-developer scale
The first area where people stumble in getting more technical is defining what technical actually means. Technical knowledge exists on what I like to call the function-developer scale1:
Hello dear paid subscribers, and welcome to the second issue of Ask Technically. A few weeks ago, I asked you all for burning questions about software, hardware, and everything in between and the response was overwhelming! I’ve got 50+ questions to work my way through, so we’ll tackle 2-3 every issue to make sure everyone gets a quality and thorough answer.
Recall that Ask Technically of course does not replace the exclusive paid content (deep dives, company breakdowns) that you signed up for; it’s just a new format I’m adding into the mix to make sure you’re getting even more out of your subscription. If you missed the last paid post about production databases, you can check it out here.
If you have any questions of your own, just reply to this email or send them to justin@technically.dev.
A Data Lake is an unstructured place to put data. It’s usually meant for long term storage and infrequent querying.
Companies are collecting more data than ever before (yada yada), but not all of it gets used immediately
A data lake is a place to drop data, in an unstructured format, usually for long term storage
Data lakes are easiest to understand in contrast to data warehouses, where schemas are defined in advance
A new trend is seeing data lakes act as quasi data warehouses, and it’s possible the categories might...merge?
You’ll often see data lakes as part of those infamous infrastructure diagrams that nobody (myself included) understands. So it’s worth understanding why companies use them, and where they fit into the modern data stack.
Hello dear paid subscribers, and welcome to the first issue of Ask Technically. A couple of weeks ago, I asked you all for burning questions about software, hardware, and everything in between and the response was overwhelming! I’ve got 50+ questions to work my way through, so we’ll tackle 2-3 every issue to make sure everyone gets a quality and thorough answer.
Note that Ask Technically of course does not replace the exclusive paid content (deep dives, company breakdowns) that you signed up for; it’s just a new format I’m adding into the mix to make sure you’re getting even more out of your subscription.
If you have any questions of your own, just reply to this email or send them to justin@technically.dev.
This post is going to dive deeper into production databases. We’re going to look at what they’re used for, popular options (SQL vs. NoSQL – what’s the difference?), challenges with scaling applications, and where databases are going (serverless, basically).
There are a lot of different types of databases out there. They come in all different shapes and sizes based on what engineering teams use them for. A few that you’ve probably come across:
Hello there my dear, loyal paid Technically subscribers.
Have any questions?
I’d like to start incorporating more of your questions into the newsletter. Between big topics (“what’s GraphQL”) and company breakdowns (“what does Splunk do?”) I usually get asked smaller questions like:
Product analytics – what the hell is it? Why is Amplitude a public company? What do product managers even do?
This Technically post will dive into how companies analyze what their users are doing in their product. We’ll cover what kinds of questions teams want answers to, how the data gets generated and moved, and what tools are out there to simplify things.
This post was graciously sponsored by PostHog, the open source product analytics platform you can self-host. PostHog helps you across the stack from instrumentation to exploration, and is like, totally free.
