The other day I had an interesting conversation over a cup of coffee with a very good developer-friend of mine. As a quick background information, professionally speaking we both like the same things, the same pretty things. We strive for somewhat good-looking and well-structured code, wanting to achieve a certain aesthetics within our IDEs with every line we add or remove. So, the next mannerism we do have in common is the act of refactoring (preferably someone else's code).
Although it does really look like we do have a lot in common, just as with various other developers around the wide world, our motives for doing what we do could not be any more different.
The Clean-Up Crew
“Caution! Construction site ahead” – Yes, we are renovating!
Simple initial refactoring before really starting out to work on the feature you currently have in progress just seems like showing your good manners to me. Be it outsourcing some code into a separate method, implementing an interface or abstract class, which can later be use for whatever you need it for. It feels like a friendly knock on the door followed by a warm and forthright handshake before neatly hanging up your coat to tackle the work within a clean and respect-filled environment.
This is what we do. We like to introduce ourselves properly to the shy code, we want the code to be our friend, and we know that we sometimes tend to get a little too attached to the method we just wrote – just because we know it so well! Although it is a very gentle way to approach a codebase – nearly as gentle as trying to pet a deer out in the woods – none the less it is very effective. We, the clean-up crew, know how to handle the existing code and, also how to tenderly push it where we want it to go, all because of properly introducing ourselves.
This may sound a little brutal right here after being bombarded with so many cute expressions, but it somehow really fits the picture! Maybe just next door or a little down the road another developer pulled up in his expensive car, using up two parking spaces, and storms the apartment carefree as ever, only focusing on what is yet to come – work, work, work.
With eyes sharpened and an excited, but still steady expression on their experienced face, they start to move furniture, open the curtains and windows, maybe even do the dishes or simply examine the fridge for leftovers or… no one knows what! Some may say, they are savage, cruel, and rude, but they are not, they are hardworking, and yes, maybe they seem to be a little cold when talking about their outcome, the code they produce.
They like the feeling of having control and maybe also like to smell the sweet scent of constructive destruction when leaving through the front door without closing it. It does not matter whichever project they can get their hands on. This is how they work best, and they do their work well.
Seeing Things, a Little Different
I was fascinated by the amount of coolness swinging within the voice of this assassin, nearly intimidated as someone being used to thinking about coding on a somewhat more emotional level (also owed my hobby of writing about it occasionally).
I guess that there are at least as many of these different types of developers as there are developers themselves, and that is amazing! So, why not, next time meeting up and talking over a cup of coffee, find out about the true drive of the one in front of you? There is much we can learn from each other, which often does extend the general technical knowledge of programming languages, frameworks, and libraries. As nature already showed us so many times, the one being able to adapt to their current situation will be the one surviving in the long run.
For us two, we agreed that, sometimes there only is the solution of “my way or highway”, and that sometimes having a relaxed coffee beforehand does wonders for the task! ☕
Top comments (2)
Great article - though in my opinion, what you describe is much more "a tool for the job" than a "general outlook on life."
There's times when code needs a gentle massage, a little love and attention. There's also times when a bug simply needs a precision strike from orbit. Some developers are better suited to either end of that spectrum, but a Good Developer should at least be able to cope on either end.
Even with those orbital strikes, we should at least have the manners to tidy up afterwards, but in the real world, we're not always afforded that time - and that is the burden we bear in the form of technical debt.
To me, the only "bad developer" is one that doesn't deliver.
Very true! Like with everything else in life, balance and adaptability is needed to succeed.
But I guess that everyone leans towards on side or the other of this broad spectrum :)