I have been working with several scenarios lately that have been quite primarily challenging in how I should work them as opposed to what work I should execute and ship. I have a mantra that is “the way work is done is as important as the work that gets done. ” Simply put, do it well, do it above the standard, and do each task to the utmost as well as meet the requirements/story, and deliver an excellent result. It is a lot harder to do than it sounds.

This is a world is where work is timed like a microwave warming up a plastic container of leftovers. Maximum energy, minimum time. The result is hot as the sun on the outside, cold on the inside, and the taste and experience of the food gone. But it was fast! Fast fast fast! The results were minimal and less than satisfying. Much like most of the work we do. Fast work, soul crushed.

This is my personal feeling, but I would prefer to do things in the right measure and in the right time window. Good work has its own timetable. I recently read an example that was comparing the work of junior developers against a senior developer with the juniors solving the problem in 200 lines of code and the senior in 20 lines. The senior developer’s work will exist with no changes until a new requirement changes it, and the junior developer’s lines will produce support tickets just as sure as the microwave warmed-up leftovers bring on an upset stomach. The senior developer took time to look over the scenarios, compared the front-to-end process, diagramed and wrote out the proposal, questioned everything, and made a strategic and calculated update. The junior developers read the request and coded what was asked and turned it in.

Good work has its right space. How you do things is just as important as the work that was completed. Often the work that is not seen such as planning, questioning, thinking, and executing makes all the difference. It is not a big design upfront effort, it is trying to solve the problem and not create anything else to have to do or repair later. This can all be agile. You can SCRUM this effort. It works with a CI/CD pipeline.

It is all about the sustainability of your work. Making a complete impact and delivering a superior result is what it is all about. I firmly believe that the rush rush rush, fast fast fast world of expectations from business units and over-achieving managers should be tamed and tempered a bit in order to just do better work. This is what Agile is all about as well. Have the story that starts the work, but the work changes and adapts based on the work and when the code actually starts, it is the lessor of the steps rather than the consumer of the entire time window.

Of course, I am preaching to the choir, but sometimes we need the encouragement to do things the best way and in a way that is sustainable, satisfying, and delivers a great result to be shipped. The work of a software developer is hard, but it should also be satisfying and sustainable. Take the time needed.