My job is not interesting. I cannot grow here. There is not enough coding. I'm not progressing in my career.
I've heard this from many people in the department I work for. If so many people say so, there must be some truth in it. Reservation systems might not be the most interesting topics in IT when others are building robots and artificial intelligence for almost every area of our lives.
On the other hand, checking these complaining people's pull requests what you can see is that the delivered code is of questionable quality. Lengthy functions, general lack of OOP, non-well-describing names, etc.
The job is boring. Still, the code could be written with care, it could have a decent quality. But no tests. No refactoring. Just adding a few lines here and there to already long functions. In fact, the quality degrades with each such pull request.
Yet, their job is boring and they cannot grow. They feel demotivated.
They don't want to put in the effort to make the most out of it.
They don't understand that if they write good code covered with meaningful tests they don't do a favour to their employer. They do a favour for themselves. They learn, they practice how to craft good code. They can try out different concepts, they can check what is working in what situation. They enhance their knowledge, making themselves more employable. It should be a clear win-win.
So what can be the reason not to do so? One reason can be that management doesn't support quality work, or only by words. This reason is also nothing more than fingerpointing. Let's take some lessons from the Navy Seals and extreme ownership. Stop blaming others and ask yourself what you could do better. Take ownership and act.
I don't want to brag, but my first pull request on the project I joined, made my teammates come to my desk and congratulate. Though I didn't do anything special. I just tried to do whatever it takes to be content with the code I submit. To be proud of it or at least to be able to look in the mirror. This required clean code, refactoring and adding tests. And yet it was not perfect. However it'll be easy to enhance it and because of well-named functions, it's easy to understand even for non-developers. For me, deliver such pull requests is the best and only true way to turn people around. But it won't work with everyone, I know.
My demotivated friends out there, who think you have not enough possibility to write code, listen to me for a second! You have more possibilities than you'd think! Refactor! Make the code better! Leave the campground cleaner than you found it! And if you really feel that quality is not a concern for your organization, find another one. But until then, do your best. Not for anyone else, but you!
This article has been originally published on my blog.
Top comments (23)
I think that's summary is fair. You certainly can improve the code, refactor and improve the code. But such an action requires you to feel empowered. If the product owner wants features, then that's what they'll get, regardless of it you want to do non functional work because it's out of scope.
I recently refactored all the select lists on our website into one template with parameters, this was to fix a bug in one of them. This decision came off of the back of chatting as a team and me saying, "If we don't fix the defect here it will sooner or later resurface". I felt empowered because the team agreed. Months and I'm sorry to say months later I have finally got passed BQA and starting code review, the empowered feeling is draining now because I know this change was huge, out of scope and not productive, was it worth it? Absolutely. Just be careful because refactoring tends to lead to out of scope refactoring.
Out of scope refactoring that the product owner and management don't want and didn't sign off on is an excellent way to get yourself put on a "Performance Improvement Plan" because you aren't a "team player". This can create considerable conflict in the team when the original author, if they're still around, takes offense at your unauthorized refactoring.
Basically, if it's not a story in the sprint, don't do it. You can recommend it and advocate for refactoring to be added to the backlog. However, going rogue with refactoring is courting trouble.
What is "unauthorized" refactoring? Do you also have "unauthorized" unit tests? Classes? Methods? Loops? Variables?
I think if you are a professional software engineer you can decide when to do what with the code. If people get offended because their code gets refactored either because it was messy when it was created or because just too many things happened around it, there is a big cultural issue in the team.
On the other hand, when I say do refactoring, I don't say that you should stop delivering features. Just always clean up around the code you touch. Nobody needs an authorization or a user story for that.
Unauthorized means outside of the scope of work you are assigned to do.
You used a military analogy in your post. In the military, if you go outside the rules of engagement or circumvent orders you will likely find yourself court martialed and earn a bad conduct discharge or perhaps a term in Leavenworth even if in your professional opinion you did the right thing at the time. While the consequences aren't as dire on a software development team, doing things beyond what you are assigned can easily land you in trouble or in the unemployment line.
I work with a lot of legacy code, code that has been under development since 90's with a lot of different people involved over the years. Refactoring of this huge legacy code base has to be done with care and planning. If it isn't, it probably will cost the company downtime and money. Maybe if you are working on a newer code base that you can get away with more. I don't have that luxury. I have to keep the factory running.
I also work on such systems. Some parts are newer, some are older. How messy the code is don't just a matter of age, but more like who touched it.
I agree that care and testing are important things. Many will not care and just add the same couple lines here and there dozens of times in a fear-driven development, making things worse. They will not even create a new function, not to mention cleaning up around. Why? Usually not because they think it needs planning and authorization to do a proper job.
I still think I (or anyone else) don't need any authorization to do the work the way, I think it should be done. The PO cannot tell me, how I should implement the feature. But I know people who think differently. The most extreme was someone, who didn't even fix the typo "Hanlder", because the PO made the typo in the title of a user story, so he helped it almost slipping into our codebase. (Code reviews are cool)
And that's why pushing back is so important. Thanks for sharing this post it's a topic very close to home for many I'm sure.
You don't know the politics of the situation, so I'l just have to agree with you on face value but in reality, what I did was right and had the backing of the team. I respect your commitment to the process. If it helps I'm not on stories, I'm on defects.
The problem is that most refactoring activities will be out of scope. If you don't take the "ownership" for yourself (e.g. work few hours later for a few days in order to accomplish the refactoring, without delaying the team's progress), chances are that you'll never have a "proper scope" for this.
I'm not defending that we should accept overwork as normal thing (it's not), but sometimes we need the push "the extra mile" in order to have a job well done feeling.
I don't see any point doing refactorings in extra hours. With that, we might give an impression that (code) quality comes for free. It does not - in the short run, in the long run, it is cheaper than writing a big mess. But tackling technical debt is rather expensive. We can see that in most of the long-running projects where people, in the beginning, were penny-wise but pound-foolish.
I personally never stayed late so that I can refactor the code. I just make it part of my development process. Just like adding tests for example - for some even that is not in the scope...
We have to find the golden mean. Which is definitely not the first version of the code that we drafted and eventually started to work, but also not something that we overengineer during weeks.
However, in my opinion, nobody should be afraid of saying "I'm not ready yet" until the code is not something that he/she would also be happy to show at an interview part of his/her portfolio.
And if the company doesn't welcome quality work. Well. Just look for another one.
I've smashed a wasps nest that's all I'm saying. I absolutely agree you should be fearless. But not wreckless.
When first starting out, you finish 1, 2, 5, 10 tasks in a very short amount of time, the code for it is absolutely horrible but the client is pleased as it does the job well. And so is the team because, well, less work they have to do.
The project manager starts making up an approximation of how much time it takes you to finish a task and starts handing them out to you at that pace.
So you keep bringing bad code in the project, really fast and you are now also pressed by deadlines for each task and can no longer provide good code and tests.
That's where a lot of people are and can't escape.
I see two main factors playing a counterproductive role
here:
1) broken window:
There is no incentive for cleaning up. It is a mess.
2) Management produces the behavior not by having wrong standards, but not reward living to these standards.
And speaking of extreme ownership: team problems are mostly management problems. Because the management doesn't own its job.
Of course you could argue that this is fingerpointing and people should be more professional. But why should they, if there is no incentive to do so?
I care, but I totally understand that there are people who don't.
I am self motivating, but there are people who are not. And that's sometimes okay.
I really enjoyed reading this. There have been times in my own software journey that this mentality escaped me (especially during some less than exciting classes). Everyday is an opportunity to grow, and there is always something to improve.
Thanks for your comment, Eric! I'm glad you liked it!
This is what I tell all the time to some colleagues, that complain all the time because their job is boring, because the mostly copy-paste similar code from other parts of the application or add chunks of logic to other methods.
You have to find joy in what you do. And one way is to care and take ownership.
Empower yourself. Not wait for anybody else doing it for you.
Absolutely love this article. could not agree more. Even though speaking of Refactoring might be a bit dangerous or misleading. I often met some of those bored employees embark in major refactorings that took ages and were not necessary at all.
But I am pretty sure with Refactoring in a pull request you mean small things, details that just improve the code you found or were working on.
The boy scout rule is a must for me (it could be fixing a typo, split a long method into smaller readables and unit testable ones etc) and adding a small unit test on everything I touch when bug fixing is another one.
Something else i dont understand when people say they are not allowed writing better code or unit test is, you estimated the feature, or you agreed with it. If reasonable code quality and unit test are not part of the estimated time for a feature, well probably you have to re-discuss your teamΒ΄s "Definition of Done".
Thanks for your kind words, Davide!
Indeed, I barely advocate for rewrite-refactorings. It's more the boy scout rule, just to clean up that area of code, that class if it's not too big.
The question of Definition of Done is really important. It's not enough to have it, but people should respect it. That's something I don't see every time. It becomes problematic when multiple teams are working on the same codebase, but not all the teams obey to the same rules...
All true, but maybe it's also a problem with the company culture, which in fact you already hinted at:
"One reason can be that management doesn't support quality work, or only by words"
But then there's your next sentence, to which I tend to disagree (but I could be wrong):
"This reason is also nothing more than fingerpointing"
Of course I don't know about the real situation "on the ground" in your company, but I've worked at a couple of companies where management and company culture were just totally not conducive to efforts to improve things - it was the equivalent of pulling a dead horse.
I mean, what if you do your brilliant refactorings, and write fabulous tests, and then nobody (including your manager) cares? Sometimes it just doesn't work, and you're better off looking somewhere else.
I mean, sometimes it's simply a lost battle, which doesn't merit your energy or good intentions.
I think there might be a misunderstanding which is definitely my fault. Many identify refactoring as an activity that requires a lot of time and that changes the layout of whole components.
Refactoring can be like that.
But it's also part of the Red-Green-Blue cycle of Test Driven Development where it cannot take much time. You don't have to change the world, just make it a bit cleaner around the places you go.
Somebody asked who pays for this. Of course the project. In the long run maintenance costs trump development costs, so you help making it cheaper in the long run. And if the project won't reach the "long run" it was not because you did a proper job.
But I also have a darker response to that money part. Many of those who complain a lot about not interesting jobs and not enough chance to code, yet they write low-quality code, they tend to spend more time on social media, news portals, in the coffee rooms, or just smoking outside. Who pays for that?
I can identify strongly with the situation you describe in your post. I have been with my current employer for almost one year and I don't have the impression I can grow as an engineer there.
However, I see myself as one of the stronger coders in my team. I come to that conclusion, since colleagues and managers come to me when they have difficult questions or tasks to get solved. This also supports my impression, that I can provide knowledge to the company while I can't get much knowledge back.
In my current project, we don't have pull requests or code reviews at all. Everyone just commits onto trunk (yes, we have svn instead of git). If the code contains errors, it will be noticed when someone is trying to use the code. Rudimentary tests have been written (mostly because I insisted to do so). Also we don't have CI.
I have tried to establish more modern software engineering processes including PRs and code reviews, but could not find much resonance in the team. Mostly I get the response changing the process takes too long, because people have to learn new tools and workflows and we have hard deadlines to meet.
I still try to do my best work everyday, but I feel very restricted in that environment to develop professionally. Do you have any advice on how I can still make the best out of my situation?
Thanks for your comment, Senpo.
I think you can still have knowledge back, in fact very much. Being a mentor for the others and showing the way to go is an invaluable experience.
Of course, for that, you need an open audience. Which you are missing if my understanding is correct.
In my previous teams, I simply did what I felt right and little by little like-minded folks we found each other and we grew together and we raised the bar for the whole team if we could. I'd lie if I said we could all the time. But I saw some people having careers turned around and who became good that kind of people who try to get better all the time. I think, one person is already a success. Maybe he'd help another.
If you completely miss the open ears, I think you have to convince management that what you are trying to introduce will save them money even in mid-term. Bugs discovered earlier, easier maintenance, better documentation (through tests) are worth a lot of money. Code Simplicity: The Fundamentals of Software can give you a lot of examples of good arguments.
I wrote about why coding guidelines are good for your team which might give some other arguments that you can use.
Focus on what value you can provide to the business using modern engineering practices and managers will help you change the way the team works.
If you still face deaf ears, maybe it's a sign that it's time to move on. As one of my former bosses told me, sometimes the best thing is to find another place.
Anyway, I wish you good luck and that you will be able to change how your team works. You'll provide a great service with that for everyone involved!
Thanks. You found right words to reach me. Now I clearly see what I was missing.
Really resonates with me π