54 items tagged “software-engineering”
2024
Preferring throwaway code over design docs (via) Doug Turnbull advocates for a software development process far more realistic than attempting to create a design document up front and then implement accordingly.
As Doug observes, "No plan survives contact with the enemy". His process is to build a prototype in a draft pull request on GitHub, making detailed notes along the way and with the full intention of discarding it before building the final feature.
Important in this methodology is a great deal of maturity. Can you throw away your idea you’ve coded or will you be invested in your first solution? A major signal for seniority is whether you feel comfortable coding something 2-3 different ways. That your value delivery isn’t about lines of code shipped to prod, but organizational knowledge gained.
I've been running a similar process for several years using issues rather than PRs. I wrote about that in How I build a feature back in 2022.
The thing I love about issue comments (or PR comments) for recording ongoing design decisions is that because they incorporate a timestamp there's no implicit expectation to keep them up to date as the software changes. Doug sees the same benefit:
Another important point is on using PRs for documentation. They are one of the best forms of documentation for devs. They’re discoverable - one of the first places you look when trying to understand why code is implemented a certain way. PRs don’t profess to reflect the current state of the world, but a state at a point in time.
For most software engineers, being well rounded is more important than pure technical mastery. This was already true, of course — see @patio11's famous advice "Don't call yourself a programmer" — but even more so due to foundation models. In most situations, skills like being able to use AI to rapidly prototype in order to communicate with clients to iterate on specifications create far more business value than technical wizardry alone.
How I ship projects at big tech companies (via) This piece by Sean Goedecke on shipping features at larger tech companies is fantastic.
Why do so many engineers think shipping is easy? I know it sounds extreme, but I think many engineers do not understand what shipping even is inside a large tech company. What does it mean to ship? It does not mean deploying code or even making a feature available to users. Shipping is a social construct within a company. Concretely, that means that a project is shipped when the important people at your company believe it is shipped.
Sean emphasizes communication, building confidence and gaining trust and the importance of deploying previews of the feature (for example using feature flags) as early as possible to get that crucial internal buy-in and feedback from other teams.
I think a lot of engineers hold off on deploys essentially out of fear. If you want to ship, you need to do the exact opposite: you need to deploy as much as you can as early as possible, and you need to do the scariest changes as early as you can possibly do them. Remember that you have the most end-to-end context on the project, which means you should be the least scared of scary changes.
Whither CockroachDB? (via) CockroachDB - previously Apache 2.0, then BSL 1.1 - announced on Wednesday that they were moving to a source-available license.
Oxide use CockroachDB for their product's control plane database. That software is shipped to end customers in an Oxide rack, and it's unacceptable to Oxide for their customers to think about the CockroachDB license.
Oxide use RFDs - Requests for Discussion - internally, and occasionally publish them (see rfd1) using their own custom software.
They chose to publish this RFD that they wrote in response to the CockroachDB license change, describing in detail the situation they are facing and the options they considered.
Since CockroachDB is a critical component in their stack which they have already patched in the past, they're opting to maintain their own fork of a recent Apache 2.0 licensed version:
The immediate plan is to self-support on CochroachDB 22.1 and potentially CockroachDB 22.2; we will not upgrade CockroachDB beyond 22.2. [...] This is not intended to be a community fork (we have no current intent to accept outside contributions); we will make decisions in this repository entirely around our own needs. If a community fork emerges based on CockroachDB 22.x, we will support it (and we will specifically seek to get our patches integrated), but we may or may not adopt it ourselves: we are very risk averse with respect to this database and we want to be careful about outsourcing any risk decisions to any entity outside of Oxide.
The full document is a fascinating read - as Kelsey Hightower said:
This is engineering at its finest and not a single line of code was written.
Lessons learned in 35 years of making software (via) Lots of great stuff in here from Jim Grey, with a strong focus on "soft skills" (I prefer the term "professional skills") around building relationships and making sure your contributions are visible.
This tip resonated with me in particular:
There is no substitute for working software in Production. I can’t believe now that I have been part of 18-month release projects. This was back in the bad old waterfall days, but even then it was possible to release a lot more frequently than that. The software we build is valuable. It builds the value of the company. When you hold it until it’s perfect, or everything you think it needs to be, you are holding back on building the company’s value. Find the fastest, shortest path to getting the smallest increment of the thing that will work into the customer’s hands. You can keep making it better from there.
And another tip on the subject of perfectionism:
When you deliver work you’re really proud of, you’ve almost certainly done too much and taken too long. I have a bit of a perfectionist streak. I want to do my work well and thoroughly. It took me a long time to learn that when I do that, it’s for me, not for the company. When I’ve reached 60-80% of the thing being as good as I want, I’ve probably done enough.
We respect wildlife in the wilderness because we’re in their house. We don’t fully understand the complexity of most ecosystems, so we seek to minimize our impact on those ecosystems since we can’t always predict what outcomes our interactions with nature might have.
In software, many disastrous mistakes stem from not understanding why a system was built the way it was, but changing it anyway. It’s super common for a new leader to come in, see something they see as “useless”, and get rid of it – without understanding the implications. Good leaders make sure they understand before they mess around.
Tools are the things we build that we don't ship - but that very much affect the artifact that we develop.
It can be tempting to either shy away from developing tooling entirely or (in larger organizations) to dedicate an entire organization to it.
In my experience, tooling should be built by those using it.
This is especially true for tools that improve the artifact by improving understanding: the best time to develop a debugger is when debugging!
2023
Tech debt metaphor maximalism (via) I’ve long been a fan of the metaphor of technical debt, because it implies that taking on some debt is OK provided you’re strategic about how much you take on and how quickly you pay it off. Avery Pennarun provides the definitive guide to thinking about technical debt, including an extremely worthwhile explanation of how financial debt works as well.
Every year, some generation of engineers have to learn the concepts of "there is no silver bullet", "use the right tech for the right problem", "your are not google", "rewriting a codebase every 2 years is not a good business decision", "things cost money".
— sametmax
Old technologies that have stuck around are sharks, not dinosaurs. They solve problems so well that they have survived the rapid changes that occur constantly in the technology world. Don’t bet against these technologies, and replace them only if you have a very good reason. These tools won’t be flashy, and they won’t be exciting, but they will get the job done without a lot of sleepless nights.
2022
The Perfect Commit
For the last few years I’ve been trying to center my work around creating what I consider to be the Perfect Commit. This is a single commit that contains all of the following:
[... 2,061 words]Software engineering practices
Gergely Orosz started a Twitter conversation asking about recommended “software engineering practices” for development teams.
[... 1,557 words]Reduce Friction. Outstanding essay on software engineering friction and development team productivity by C J Silverio: it explains the concept of “friction” (and gives great definitions of “process”, “ceremony” and “formality” in the process) as it applies to software engineering, lays out the challenges involved in getting organizations to commit to reducing it and then provides actionable advice on how to get consensus and where to invest your efforts in order to make things better.
Visual Studio Code: Development Process (via) A detailed description of the development process used by VS Code: a 6-12 month high level roadmap, then month long iterations that each result in a new version that is shipped to users. Includes details of how the four weeks of each iteration are spent too.
The End of Localhost. swyx makes the argument for cloud-based development environments, and points out that many large companies—including Google, Facebook, Shopify and GitHub—have made the move already. I was responsible for the team maintaining the local development environment experience at Eventbrite for a while, and my conclusion is that with a large enough engineering team someone will ALWAYS find a new way to break their local environment: the idea of being able to bootstrap a fresh, guaranteed-to-work environment in the cloud at the click of a button could save SO much time and money.
Contributing to Complex Projects (via) Mitchell Hashimoto describes in detail his process for understanding and eventually contributing to a complex new codebase. I picked up a whole bunch of useful tips from this.
How I build a feature
I’m maintaining a lot of different projects at the moment. I thought it would be useful to describe the process I use for adding a new feature to one of them, using the new sqlite-utils create-database command as an example.
[... 2,850 words]2021
PAGNIs: Probably Are Gonna Need Its
Luke Page has a great post up with his list of YAGNI exceptions.
[... 1,289 words]YAGNI exceptions (via) Luke Plant provides his collection of things that you probably ARE going to need in a project, where adding them later is painful enough that it’s worth the up-front investment. I really like these as a concept, and I’m coining the term PAGNI—for Probably Are Gonna Need It—to describe them.
Business rules engines are li’l Conway’s Law devices: a manifestation of the distrust between stakeholders, client and contractor. We require BREs so that separate business units need not talk to each other to solve problems. They are communication and organizational dysfunction made silicon.
2018
Software Sprawl, The Golden Path, and Scaling Teams With Agency (via) This is smart: the “golden path” approach to encouraging a standard stack within a large engineering organization. If you build using the components on the golden path you get guaranteed ongoing support and as much free monitoring/tooling as can possibly be provided. I also really like the suggestion that this should be managed by a “council” of senior engineers with one member of the council rotated out every quarter to keep things from getting stale and cabal-like.
Migrations are both essential and frustratingly frequent as your codebase ages and your business grows: most tools and processes only support about one order of magnitude of growth before becoming ineffective, so rapid growth makes them a way of life. [...] As a result you switch tools a lot, and your ability to migrate to new software can easily become the defining constraint for your overall velocity. [...] Migrations matter because they are usually the only available avenue to make meaningful progress on technical debt.
2013
Are there any good bootcamps, such as Code Fellows, DevBootCamp for mobile (iOS/Android)?
Big Nerd Ranch have been offering iOS and Android for several years now. A friend of mine went in the iOS course a while ago and spoke highly of it—he has since released an app to the App Store.
[... 62 words]How can I convince my boss that I should dedicate time to clean an important part of our code base?
It sounds like your boss needs to learn about the concept of Technical Debt: http://www.codinghorror.com/blog...
[... 42 words]What are ways to avoid getting discouraged while searching for a job as a software developer?
Do you have any programming side-projects? If not, I suggest starting one. You’ll learn a bunch, it will impress interviewers (and help you pull ahead of other candidates) and it will help you build confidence in your own skills.
[... 83 words]Will a professional programmer lose anything if he doesn’t learn object oriented programming?
Yes. OOP is a very important programming concept—a professional programmer who is not familiar with it will be unable to understand vast swathes of high quality existing code and will have a great deal of trouble passing interviews or contributing effectively at great companies.
[... 95 words]How do I become a global nomad as a software engineer?
Go freelance, start working on projects and build up a reputation as an excellent engineer who gets high quality work done on time. Build up a large roster of satisfied clients who wish to work with you in the future, and know how to successfully work with you via email and video conferencing. Now pack your laptop and head off around the world.
[... 126 words]What are key considerations when building behind the firewall web apps?
CSRF and XSS are still important: don’t leave any security vulnerabilities which might allow an evil website out on the internet to run JavaScript that steals data from your behind-the-firewall web application.
[... 49 words]What advice would you give to a new technical co-founder at a startup?
It sounds to me like you’d be better off seeking an engineering role in an existing, relatively mature startup (one with 5-15 engineers) rather than looking to be a technical co-founder of a brand new company. Startup engineering is likely to be pretty different from what you’re used to, and there’s no better environment to learn than a fast-moving company that already has a small and highly talented group of engineers.
[... 102 words]What is the best resource for someone who is non-technical to learn about computer programming/creating software?
Learn to program. You don’t need to learn programming to the standard where you could work professionally as a software engineer, but having enough programming knowledge to write some simple programs and automate some simple tasks will make you enormously more capable when it comes to working with programmers—or in business life in general.
[... 135 words]