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 am a self-taught developer from Argentina currently living in Spain. I am passionate about improving my technical skills and helping others do the same.
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 am a self-taught developer from Argentina currently living in Spain. I am passionate about improving my technical skills and helping others do the same.
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.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
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.
Indeed, is our responsibility as the technically capable in the conversation.
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.