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 th...
For further actions, you may consider blocking this person and/or reporting abuse
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.