Think Like a Software Developer
More than lines of code, it’s the mental approach that matters
The learn to code movement has convinced many people across all professions that they need to learn to write software. But even more important than knowing how to write lines of code is being able to think like the very best of developers. This unique way of thinking is something you can use in many situations, whether or not you ever write a single piece of software.
- Expect change
- Prepare for the worst case scenario
- Make one big problem into several small problems
- Automate first steps
Working with software is wonderful because it can be changed easily. Working with software is horrible because it usually does.
Experienced developers make life easier on themselves by expecting change and planning for it. We expect that requirements, timelines, personnel, and basically everything else could change quickly without notice.
How do we accommodate change? With more software, of course! We expect that our code itself will change many times each day, so we use version control software like git so that several changes can be merged together and we can keep working. We learn how to use design patterns for organizing code in time-tested ways so that large swaths of our code can change without disrupting the rest of it. We write code that tests other code so that we can be notified if it does things other than what we expect it to.
We expect change and design our workflows around it.
Prepare for the worst
Edge case: An unexpected sequence of events that causes software to work in undesirable ways.
No one wants things to go wrong, but experienced developers have seen it happen enough that they build systems to notify and protect them when it does.
In some ways, this seems counterintuitive. Experienced homebuilders don’t expect houses to fall down. Structural engineers don’t expect bridges to collapse. But the best software engineers are the best at preparing for unexpected, sudden, and catastrophic failure.
Experienced developers know that things will go wrong in ways that can’t possibly be imagined right now. So the best I can do is build a system that will tell me when that happens. Then I can fix it.
Netflix is famous for doing this well. They wrote software that does nothing but try to destroy other software so they can see if their recovery systems are working correctly.
Part of this skill is to be able to think about all the ways things could go wrong. What if the network goes down? Might someone type in a really long word with no spaces? Are there any funny characters I might encounter? Thinking this way is so difficult that software teams often hire a whole group of people (QA testers) who do nothing but think about these worst case scenarios.
Make one big problem into several small problems
Decompose: break a complex entity into several simpler elements
Developers aspire to solve big problems. Sometimes they are so big and so complicated that they are too difficult to think about as a single problem. So we learn the skill of solving complex problems by rephrasing them as several small problems. Then these smaller problems can each be solved on their own, sometimes in an easier order or by several different people.
Automate first steps
Ten years ago, joining a new open source project or starting a new job involved several days of installing software. Developer Zed Shaw recommended that you plan on spending 40 hours when setting up a new Ruby on Rails server.
Today, every major programming language includes the ability to install all dependencies with a single command.
New developers at GitHub, thoughtbot, and elsewhere run one command to install all the software they need to start coding. On their first day.
Why would someone spend the time to build such a system? It makes it much easier to invite anyone to collaborate on an open source project or add a new developer to a team, full time or contract.
What are all the steps involved in getting started on a project that you manage? Could that be automated, or at least documented?
Developers are motivated by completing projects and getting them into the hands of customers. This often matters more to them than receiving credit or being recognized. It’s called shipping.
When describing a project that goes on and on without reaching a conclusion, developers often exaggerate and call it a death march, words more commonly used to describe genocide, not a failure to copy code to a server.
Developers talk about discouragement and burnout that result from not being able to complete a project.
This drive to complete, deliver, deploy, and ship is at the core of what developers think about every day.