If you are interested in reading this article in Spanish 🇪🇸, check out my blog:
The Developer's Dungeon
For many years I believed that the only thing that constituted being a professional was being paid for doing something. I practiced Muay Thai for many years, so being a pro fighter meant being paid for fighting (apart from the fact that you use fewer protections during fights and sometimes rounds are longer).
In a previous life, in a previous career, one professor told me that a professional would not speak about the things he has no knowledge about, he would not lie. I thought that was a very cool idea so I added it to my definition, curiously the other day a friend told me that I don't speak a lot, but when I do I always say something smart, so that professor might have influenced me more than I have realized at the time.
Until a few years back I thought I was a professional developer, it wasn't until I read The Clean Coder by Robert C. Martin AKA "Uncle Bob" that I started analyzing my processes, my actions, mistakes and realized that maybe I wasn't holding myself to the correct standards.
In this article, I am gonna point out my past mistakes and how I think a real professional should behave.
The Fake Professional
For the first 2 years as a "professional" software developer, I worked at multiple consultancy companies, everything had to be done fast, sometimes there was no QA team, sometimes no designers, everything was in a hurry and the situation was pure stress, but those are not excuses. Out of my own lack of self-confidence, I have been pushed around to produce sub-par work, but it was me who let it happened.
- Out of laziness, I did knowingly delivered faulty software.
- I didn't write a single unit test in 2 years.
- I didn't produce the best code I could, I went for the fast easy solution multiple times, bringing future bugs and problems.
- I have accepted to 'try' to deliver on certain deadlines even when I knew it was impossible to get it done in that timeframe, even working full weekends multiple times.
- I have been coerced to accept certain solutions from people that were not technically capable enough to understand the real implications.
- Out of my own behavior, I have seen code rotten to the point were application development becomes incredibly slow.
- I have wasted time during working hours.
- I thought that it was the obligation of my employer to teach me the right tools and practices for my job.
During those years I thought this was what working as a developer was like, I mean everyone around me was doing the same thing, the projects had no tests, management called all the shots on how things should be implemented and when. My word as a developer was not respected one bit and now I finally understand why.
I am pretty sure that I am not the only one in the community that has done this, I have talked to many developers throughout the years to know this is not strange.
Unfortunately, I am starting to think we don't have a profession. We don't have a set of rules, a set of common practices, ethics that every developer should follow in order to be considered a professional developer. We also don't have a common organization that will take the necessary actions when a developer behaves against our common set of standards.
The Goals
I don't agree with everything "Uncle Bob" says but I do agree that until this happens we should at least start behaving like professionals. Here are a few rules that he has pointed out:
- The code that I produce will always be my best work. I will not knowingly allow code that is defective either in behavior or structure to accumulate.
- I will produce, with each release, a quick, sure, and repeatable proof that every element of the code works as it should.
- I will make frequent, small releases so that I do not impede the progress of others.
- I will fearlessly and relentlessly improve my creations at every opportunity. I will never degrade them.
- I will do all that I can to keep the productivity of myself, and others, as high as possible. I will do nothing that decreases that productivity.
- I will continuously ensure that others can cover for me and that I can cover for them.
- I will produce estimates that are honest both in magnitude and precision. I will not make promises without certainty.
- I will never stop learning and improving my craft.
The Real Professional
Since those problems became clear for me I have been behaving against a higher set of standards, I have fallen into the 'Software Craftsmanship' community.
Every piece of code I produce has a set of tests attached to it. Since the project didn't have tests, I started doing tests on my own and improving the code, eventually, the team joined and know we have quite good code coverage.
When I write a bugfix I don't go for the easy fix, I first come up with the best implementation, sometimes it does happen that the best implementation is not viable because of external constraints, but that decision is made by conscious analysis, not out of laziness.
If someone that doesn't belong to the development team tries to impose a deadline on me I analyze if that deadline is feasible, if it is not I hold my ground and say that under those requirements that deadline is simply not possible, then I try to find a compromise that can work for both parties.
During my office hours, I always work. It is my job to do it, I am being paid to do it. Nothing to argue.
Although there are certain situations where your employer is responsible for paying you to improve yourself (if for instance, you need to learn certain tech so you can implement it in the company), I don't leave my general improvement to my employer, I am in control of my career.
When I go home I read books, I listen to podcasts, I code on other paradigms and languages, it is my responsibility, and also is super fun 😄
I have to say that so far my career has improved a lot since I changed my mindset, I have been recognized by my peers and coworkers, I have taken responsibility for my triumphs but also for my mistakes. Being a professional is not easy, it is far easier to not have any type of standards for yourself, but there is also no reward in doing it the wrong way.
I hope you liked the article, please let me know in the comments if you have seen others or even yourself behave like this before, do you think I am missing something? also, let me know in the comments.
If you like this post please share it 😄
Top comments (32)
IMHO you don't have to be perfect 24/7 to be a professional. For me, professionalism is more related to credibility than anything (i.e. Do you trust a surgeon to conduct medical operations on your body? Do you trust a structural engineer to build the apartment building you will live in?). In other fields, there are licenses and tests to evaluate the minimum level of skills, while software engineers don't have to take bar exam. I think this is why many developers suffer from imposter syndrome, and often push themselves to the edge. You are constantly improving yourself and making sure your codebase is clean, but it has little implication to clients' trust. Because there is no "construction manual" for software engineers, the only way to gain trust from clients is through communication. Tell them what you can do and what you can't do, and I cannot agree more with your professor: you should not lie as a professional. I am sure your rules will help many developers, but at the end of the day, all it takes to become a professional is the minimum skills and honesty.
"but at the end of the day, all it takes to become a professional is the minimum skills and honesty."
I would add communication to this as well. Communicating is so important.
I agree with you, the rules are just a guide, I don't believe that you should be perfect. But I believe that you should be honest and hold yourself to a higher standard, bring your A game. Which is not what I was doing in the begining, still I was being paid. Again is not about the results but about our actions and dispositions in relation to the work we produce. At least that is what I tried to say ahah
What you read on the web or in books is very different from what happens in companies. There are A LOT of companies that don't create perfect software. It's not because their devs are "not professional" it's because the companies don't give them the time or environment.
Tbh there is ALWAYS something to improve...if you work on an application for years you will look at old code and just shake your head. Also there might be new cool stuff out there you could use for older parts of the application. But you will usually not get the time or permission to do that.
Developing is also about the efficient use of time, since time is money, which means most devs can not work perfectly.
I agree, in reality nobody creates perfect software, all development is about doing the best you can with the constraints you have. Still that does not prevent you from doing the best job that you can. I didn't say you should be perfect, I say that you should bring your A game. Achieving this process is about succeeding with the actions you take, not the results you produce. Even behaving 100 % correct, the software can still suck and the company can go down. That is not the point
I kinda agree. People should always try their best. In the end it probably won't matter that much, since a lot of people work on the project and some probably underperform.
Imo this is a dangerous topic. Imposter syndrome is already mentioned. I don't really think that it is possible to always bring up your A game. This can easily turn into burnout and frustration (because some people are working below your standards which will influence the final product).
If you work with people who always give their best you will also work better...and if you work with people who underperform there is a high chance you'll also underperform (because you don't get rewarded for working better, you don't earn more, your working ethos does not influence others etc...).
I think you are professional if you realize you have to leave the current job for your own good.
Disagree with the first paragraph - and the author disagrees too. If you behave like a professional, others will soon follow and the processes will improve. Seen it happen many times.
Unfortunately in many places the people calling the shots are in fact not well-equipped to do so. One of the things stated in Clean Code is also that we, as professionals, have a responsibility to push back against those calling the (wrong) shots.
They see only their own perspective and that is usually short-term. Always taking the shortcuts and leaving a mess of technical debt behind you will spiral into a disaster.
We need to make them understand that investing some time now in cleaning up is worth it in the long term perspective.
I have never worked in any company where there was a remit to deliver code that doesn't work, or is sloppy or a mess. These things are made by the software engineers, not management
Code that doesn't work is quite a fluffy term. Of course the end user need code that fulfills their needs. But code that works can be a horrible experience for the next developer having to make a change.
Have you never been pressured by a deadline which meant you could not make the right solution?
'the right solution' is also quite a fluffy term. The reason we write unit tests and act 'professionally' is that it is proven time and time again (in my experience anyway) to be the fastest way to develop software. I keep seeing this idea of 'pressured by a deadline' which somehow means I throw away all the tools I know work, when I know that the way to meet a deadline is to stick to my principles as much as possible. I've seen the fallout when teams don't do this - the code damage lasts years, the pschological damage probably longer. Obviously there are judgement calls to be made - you can't rewrite the whole thing if you have a mess, but you can start small, and write tests for everything that you add and change.
You and I know that sticking to principles is indeed the only way to make deadlines. But I have met plenty of people who clearly either doesn't know or doesn't care. And even though I (want to) expect from my fellow developers to know this, I don't expect it from project management. I see it as my responsibility to teach them this if they don't know it.
I don't know how bad of a mess you have experience with but the one I have experience with is pretty bad. Even starting to make unit tests was hard. We're moving towards a better place but it is a bumpy ride getting there. That combined with a lot of changes consisting of single code line changes means the overhead of setting up necessary test data to hit the line in question far outweighs the time it takes to do the change. It is an investment and to do investments we need to argue the value it provides. Well and that's when we're back at our responsibility to argue that case.
Indeed, is our responsibility as the technically capable in the conversation.
Seeing as the word professional means "engaged in a specified activity as one's main paid occupation rather than as a pastime." I am a professional. Development is what I get paid to do, and the main thing I do to get paid.
The word you are probably more-so trying to use here is about how skillful you are, or if you are an expert in the field.
A profession is not only defined by the fact that you are being paid but also by involving prolonged training and qualification. This article tries to make the point that being paid alone doesn't make you a professional developer, in my opinion, it needs to be accompanied by a minimum set of standards and ways to perform that occupation. For me, this is a basic requirement, after that is met, then, of course, you can be more skillful or not. But intentionally delivering faulty code, not testing, not being honest does not constitute a skill you gain, more of a basic requirement.
Reading this article on Friday Morning (India) when there's no pressure. All retrospective calls are done. This post gives a chance to retrospect and think carefully if you are actually working in the right frame. May be its not right for every professional but this is more like a guide, there is no hard line but dots and patterns need to be followed.
Thanks for this article
Thank you for the kind words and the deep understanding of what I was trying to say. Have a great Friday
Indeed you are right, no reason to say sorry 😄 . It is true that I am referring to meaning as you mentioned. I thought it was clear, but it looks like I am wrong. In my mind, there is no reason to have a discussion about the denotative meaning of a word so I would not write a post about it.
It could also be a deficiency in expressing myself in English since the same type of questions didn't pop up in the Spanish version of the article.
If you're being paid, you're a professional as simples as that
I disagree, I was being paid but I was not delivering the value I was being paid for, still the money was flowing. Just being paid for it is no measure of doing a good job.
But value is not binary and you can always deliver more value, it doesn't matter what you do, calling someone FAKE because he/she doesn't do X or doesn't deliver the amount of value that YOU consider sufficient, in the narrow field that you're looking is just not right :) I liked your post for the most part and I understood what you meant but life is complicated, sometimes the MOST valuable thing you can do is not writing tests, doing something dirty and quick, different situations require different actions, at the end of the day what TRULY matters is bring value to your final user, so if you're being paid it's a good indicator that you're bringing value, ofc you could always do better, and you should strive to always to better, but calling someone FAKE because he/she don't or can't do what you had the privilege of doing in the situation that you were, is very arrogant I'm sorry
There is stuff here that I agree with and stuff that I disagree. First, my article is not a way of blaming others or saying that someone is not bringing specific value, is a self-analysis of decisions I made in the past, and how I think I professional should behave, especially myself, if you (by you I don't mean precisely you), on the other hand, have a different set of standards that is perfectly fine.
Nowadays I do think that not providing tests for your solution is not delivering the value you are being paid for, your employee is paying you to bring a solution to a certain problem, if you don't have tests, are you completely sure your solution works? you tried it a few times so it is safe? I think we can all do better than this. So I don't agree with the part of not having tests.
But I do mention in the article that there are times where there are external constraints and indeed sometimes the easy dirty solution is the best option, but that option should be taken with a conscious decision and not because of laziness so in that regard I think we do agree.
I also agree that the end goal is to bring value to the user, but again if you take a look at the things I did before coming to this conclusion, was I really bringing value to the user? You don't have to read the entire list to realize this was not the case, just the first one is enough "Out of laziness, I did knowingly delivered faulty software".
So finally, if you have done any of the things I did doesn't mean that you are fake, but I was doing all those things, I was absurdly behaving below what I consider a basic set of standards and I shouldn't have been paid for my work. But again, there is no other way of learning that making mistakes, I have done those mistakes and it made me realize how I want to behave.
I would suggest not using words like fake and real in the future i know your intentions were good but this type of words bring the worst in people and are very toxic
That is a good advice, in the future I will reconsider the unwanted implications that words might have on people when reading my articles.
I have recently spent time in an environment like that of the "Fake Professional". It's easy to forget, and some people don't know that there are in fact standards; for instance IETF. There is also the ACM Code of Ethics.
There is a troubling lack of accountability though, maybe the real professional is someone who holds themselves accountable.
Couldn't agree more
Muy bueno, lamentablemente las circunstancias no son las ideales
Hola Alexis, a que te refieres con que las circunstancias no son las ideales?
Is any developer sure they are a professional? haha
True ahaha
Not convinced about the always work bit. If the company pays for me to get drink on a "team bonding evening" on Thursday night, they can sure as hell pay for my hangover Friday morning!
True that is definitely an exception ahaha. Thirsty Thursday is always followed by fucked up Friday.
Some comments may only be visible to logged-in visitors. Sign in to view all comments.