The worst part of development
Building software requires so many steps in parallel: writing code, unit testing code, some manual testing, occasionally hopping over to Postman, three Stack Overflow tabs, the “asynchronish” Slack messages (grr)… you get the point.
We know from experience that just writing code demands a huge amount of attention and deep thinking. Every frustrated Google search and every rebuild-and-try-again chips away at our mental resources. Every “am I doing something wrong? distracts our colleagues. Every pull request that gets sent back for changes (needed as the changes may be) halts progress on another issue and derails a valuable train of thought.
So why is our collective response to accept that development is a messy process, add another monitor or two, and throw some line about “multitasking in the job description (which was probably already badly written anyway)?
How on earth do we expect to write – to design – good software like that?
180
What if we didn’t have to multitask to that extent?
What if we didn’t have to cobble together our understanding of an API from Slack threads and Postman experiments?
What if we were confident enough to only download official docs and work offline? (Psst… DevDocs…)
What if we never manually tested our code before we shipped it?
The Holy Grail
Maybe I’m nuts. Maybe this is too lofty a goal.
Except that all of those things are possible. Force more efficient communication. Document your code, whether it’s self-describing or needs another doc. Study your framework. Use automated build tools. And for the love of everything holy, write better tests. None of it is hard.
I dare you: the next time you have to fix a bug… don’t run your app.
If you’re scared to push code without running it manually, you don’t have a good enough support system. Period.
Whether that support system is pair programming, more focused coding sessions, comprehensive tests, robust build pipelines, better infrastructure, or better engineers (or all of the above), I could care less.
Bugs will still happen. But you’ll spend less time fixing them. And less time introducing them in the first place.
Be the engineer you wish you had.
Set an aggressively high bar, and do not back down.
Top comments (0)