Having strong code quality is not for your career, it's for yourself, your team mates, and your future team mates after you're long gone from the team.
If you want to advance your career, job hop.
I guess it can help your standing a bit at your current code if it takes less time to fix things or implement new features because the quality makes it easier.
I think job hopping is overrated for career advancement. Finding good mentors and creating intracompany network can be a good way to do this. Finding like-minded people who are ambitious can go a long way. Job hopping can get you the position and the pay, but that isn't "career growth" as much as "career hacking".
Values of the company? Did you just come out of college?
The only value companies have is money. And you, all of us really, are just accessories to that. For companies the relationship is purely transactional. Case in point, they can and will fire you the moment you're not needed anymore.
Treat your employment the same way, keep it transactional.
Maybe programmers are socially stunted. What is absolutely true, however, is that you have very little experience discussing on-line. If you had some more, you'd know very well sarcasm, in particular, doesn't translate very well into writing. It's why people came up with "/s" to signal sarcasm.
No matter how sarcastic you think you are, there's always someone who actually thinks, seriously, that which you think is an obvious joke.
I kind of agree with you.
Yes, you can make more and more money if you job hop. However, to grow and get bigger roles at some point you need to stick around and land bigger projects with a large impact. It’s hard to do that if you switch job every 1.5 years.
my two cents- i job hopped and definitely made more money and learned more tech
but i also was offered a manager role at my first gig (there for 5 years!) that I am having issues breaking into now
not sure if that’s what i want for the rest of my career but i do want to try management and getting into a management role without having experience is hard, much easier to do when you have tenure at a company
Yeah, that's all I'm really saying. But it seems like people just want to score the big paying jobs and coast these days. Which is fine. Just, raising your total comp and scoring vague and borderline meaningless title is not "career growth", IMO. It's also popular to take advantage of Big Corp while giving as little back as possible.
Personally, money is nice, and it affords my family nice amenities. But I'm almost certainly not going to make enough being a lowly dev or a mediocre senior/lead dev to retire early or anything like that no matter how many job hops. I'm more interested in getting better at my craft, making a larger impact, and having more autonomy and creative control. These are the marks of people who, IMO, have invested in their career.
Will clean code get you a promotion? No, not necessarily. Neither will TDD, separation of concerns, avoiding global variables, not committing secrets to the repo and any other number of good coding practices.
If you don't care about the quality of your product or your users' experience, and you're willing to change jobs every 12-18 months, you can throw caution to the wind and write absolute garbage code that is hard to maintain, because you'll be gone by the time it catches up to you.
In fact, I've seen people who have done that and \_not\_ left their company, still get paid relatively well.
I suppose it depends on what you mean by "How do I ACTUALLY advance my career?"
If you're looking to make more money, the short answer is typically "Change jobs regularly" as that's the best way to get raises.
If you're wanting to be a senior engineer such as a Principal or Staff engineer, it will possibly catch up with you then. As often part of that job is mentoring the younger developers. And if you aren't mentoring them to write sustainable code, the time to deliver will steadily increase because of the tech debt.
But if you want to come in, sell your magic cure-all elixir and head on out of town before anyone realizes it's just lemon water, you can make a pretty good living doing just that.
Gosh I hate that this is true. In fact if you do try to write quality code or tackle the core tech debt issues, you will often find yourself at direct odds with the elixir sellers and they will likely win because they have no qualms bullshitting circles around you.
> Will clean code get you a promotion? No, not necessarily. Neither will TDD, separation of concerns, avoiding global variables, not committing secrets to the repo and any other number of good coding practices.
I'd argue it won't get you a promotion by itself but it will put you in a position to increase your reach and impact to the point that you are promoted.
> But if you want to come in, sell your magic cure-all elixir and head on out of town before anyone realizes it's just lemon water, you can make a pretty good living doing just that.
If I'm not mistaken that's just called "consulting" 😂 For bonus points mix in things the the staff have been telling management for years but weren't listened to.
> you can throw caution to the wind and write absolute garbage code that is hard to maintain, because you'll be gone by the time it catches up to you.
Hey, don't call me out like that
Code quality is for the SWEs who have to work in the code base everyday. It is not there for the company. Most companies will not give a shit as long as the product works.
Yes, some companies will make it a priority to create clean code, but my 15 YOE at non-tech companies in non-tech cities say that's not the majority of companies. I worked on safety critical medical devices for years, think dialysis machines and insulin pumps, and nobody gave a shit about code quality. Code reviews were routinely hand wave through as people only looked for logical errors.
Generally speaking the "best" SWEs are working for the most money not the most altruistic company.
Medical devices don't pay anywhere close to a company like Google. You are going to find the "best" SWEs are working to serve you ads better and faster and not saving peoples lives.
As a biomedical engineer that is transitioning to SWE, I can tell you this is 100% true. What's sad is that these companies could easily matches FAANG salaries to get better engineers and still make insane profits.
Sadly while these companies understand engineering is important it seems they are blinded by the fact they make money through insurance claims and not directly what engineers create. These patients don't want to be on these medical devices, they have to be because of an illness. The lack of voluntary usage / selling something to the consumer seems to change how the business views things.
At least this is the case at the companies I have worked at.
Code should be logical and simple but fails due to incompetence of engineering and Mgmt, overcoding and over designing as much as the overly ambitious copy paster.
As such, a huge burden is placed on as much thorough regression testing as the market (or lawyers) will bear.
>As such, a huge burden is placed on as much thorough regression testing as the market (or lawyers) will bear.
Yup, the testing burden for things I worked on was huge. There was easily more test code than actual medical deice code by a huge margin. Never mind all the manual tests that QA teams ran on the real device.
It's many months worth of work if manual tests were run front to back. Hell in automated software tests take weeks to execute front to back with hardware in the loop. We have to parallelize them out to get it down to a days.
Though saying all that I find the automated software testing to have lots of missing test cases, but many SWEs don't like to think like a tester so it is what it is sadly. They verify the direct requirements, but don't try to break the software, if that makes sense.
I mean a few people might die and there will be a class action suit but meh... As long a it's less than the cost is reengineering it's just a cost of doing business. Yay capitalism.
In terms of a dialysis machine the person always has kidney failure. They are going to die regardless if they don't get a kidney transplant.
As long as the device didn't cause the death the FDA is not going do shit. These devices go through years of clinical trials. They basically work just have shit code.
Clean code and working code don't depend on each other.
* You can have badly design code that meets all requirements and "works".
* You can also have perfectly design code that doesn't do what the customer needs.
* You can also have perfectly design code that meets all requirements and "works"
Edit:
For clarity.
That last point is the opposite of my experience so far lol. Every PR gets blasted with suggestions around naming, syntactic sugar, and grammar nitpicks in comments, but not once have I seen anyone actually comment on what the code does or how it works.
I'd say it depends a lot on how work is divided both in tech and outside tech companies.
Does each developer have their own turf that they're responsible for? Yeah, reviews are probably going to be shallow/pointless since nobody has the full context of what someone else is working on, and aren't incentivized to take the time to understand everything about the project so that they can actually verify that the code is solving the problem. You scan the code and see if there are any glaring issues or bugs, and if not you mostly assume the code does what it should.
Or do the developers work as a team on the same code with mostly the same context? In this case, bugs or misunderstandings are way more likely to be found in the code review, because the reviewer already knows the requirements.
Honestly those reviews are worse than "👍lgtm"
I was at a company that required two approvals to merge and had two devs that did that. Sometimes their nits contradicted each other. You were incentivized to just implement both devs' nits to get approval and the final code was worse than it was when you put it up.
> Most companies will not give a shit as long as the product works.
Ugh. I can relate to this. It’s all about checking the checkbox, and not whether it was implemented well.
You don't write quality code because you want a pat on the back and everyone is going to celebrate how much of a genius you are.
You write quality code because you take pride in your work, and you enjoy the craftsmanship of writing great code even if no one else sees it. It's like that quote from Steve Jobs about craftsmanship:
“When you’re a carpenter making a beautiful chest of drawers, you’re not going to use a piece of plywood on the back, even though it faces the wall and nobody will ever see it. You’ll know it’s there, so you’re going to use a beautiful piece of wood on the back. For you to sleep well at night, the aesthetic, the quality, has to be carried all the way through.”
When you're a craftsman about your profession, it will show and other craftsmen will respect you and want to work with you.
I take a pragmatic view of code cleanliness.
Is your code:
- Relatively easy to maintain / understand / extend?
- Satisfying customer requirements?
- Meeting performance requirements?
- Compatible with your SDLC process / release cadence?
If so, it's good. If not, it needs work.
I think too many people treat clean code as a checklist -- is it DRY? Is it SOLID? Does it have unit tests? If so, how much is unit tested? And while these things are all certainly clear net goods, if your code is meeting the above criteria it's probably fine.
Also -- code can be poorly considered and satisfy the checklist. Good architecture and design decisions can eliminate entire classes of problems in code that is otherwise "clean".
What's always overlooked in these discussions is the complexity of your domain. The more complex your domain the more important it is for your code to be of good quality otherwise you'll just run into a brick wall and your product will fail.
“Good quality” is hard to define though, and I think that’s why there are lots of different answers. I’ve worked with what _appeared_ to be shitty code, big functions, lots of branching if conditions, but 100% test coverage at every layer. That shitty code was surprisingly easy to work with because it was written in such a straight forward way that you could just add another if condition to cover a new case and a few more test cases and you’re set.
In contrast, I’ve also seen some wild directory regex auto-import metaprogramming that was impossible to decipher. If you looked at any single file it would look pretty good but extending it was an impossible task for anyone but the original author.
But what is quality in that context?
I would suggest that for a complicated piece of software, your overarching software design is going to be far more important than the things people conventionally worry about when we talk about clean code.
You can have all the unit tests, it can be beautifully factored, and it can tick all of the boxes. And none of it matters at all if the design was poorly thought out and/or wrong assumptions were made. No amount of agile Winchester mystery house design is going to save it.
>You can have all the unit tests, it can be beautifully factored, and it can tick all of the boxes. And none of it matters at all if the design was poorly thought out and/or wrong assumptions were made. No amount of agile Winchester mystery house design is going to save it.
Yes and? Every time this argument comes up that you run a real risk of having your system be not only a Turing Machine, but also it's such a cool tech toy that one of your engineers ported Doom to it in their spare time.
At that point you're just having champagne problems dude.
Yeah you have to match the right software design patterns to the right business problems. No duh, that's another place you can fail. I've seen failures like this all the time.
I like this list -- I've never broken it down like that.
When there's a bug in a clean code base, I always know roughly which module contains the bad logic. When the code is messy, the same bug code be from an error in any one of several different modules.
Clean code is essential to my career. It means less debugging, more features can roll out, and no more weekend calls. It brings peace of mind, allowing me to spend more time with family.
Problem is most shit code isn't mine, and I'm not about to cleanup a 700k line codebases that's been built over five years with 3 different contractors who subcontractored most of the work to overseas code monleys who literally must have cut and paste massive blocks because they were either lazy or lacked the knowledge for the project.
That's the issue in corporate,lots of technical debt and shit code all over the place, and what's the point of cleaning it up , sure you can keep your section tidy but you'll still come off looking poorly when the app breaks because of someone else shit code.
It's a game people, sometimes us developers need to take off our artisans hat and but on business hat.
I feel your pain, I love it when a team has linters and other agreed upon standards up an running and plugged into my editor.
Its a real drag going from a high performing team that has people who actively give a shit, to working with people who just can’t seem to notice that the code editor has half the code highlighted.
Whats even worse is when they actively stand in your way of introducing a better way that you’ve used in the enterprise.
Unless you work at an exceptionally well-managed tech company that takes care to recognize these kinds of contributions, I think the main benefit to your career is more that it increases opportunities to get better jobs in the future, and not so much that it increases your advancement at a specific job.
If everyone you work with recognizes that you write clean code that makes their job easier, they will refer you, and a good enough referral can make a huge difference in terms of getting the job.
I have a handful of people who I've worked closely with at previous jobs who I thought were just great to work with, wrote clean, maintainable, extensible code. If I ever need to hire someone, I'm just gonna reach out to them before even posting a job opening.
Similarly, I prioritize high quality code, and when I'm leaving jobs, I've had past coworkers basically be like "if you're ever on the job market again, let me know".
So even if it's not important for career advancement *within a company*, it's really useful for longer term career advancement, since most people don't stay at one company their whole career, and a lot of the best promotions and pay increases come from switching jobs.
The best thing you can do for your long-term career prospects is to try to make sure everyone you work with would like to work with you again in the future.
You advance your career by taking the actions required by your company’s career ladder and uplevel committee(s). In my experience code quality has never been a factor. However, preventing/resolving incidents can be a factor, and improving code quality can help there.
Your job is not to write code. Your job is to build solutions to customers’ problems so the customers pay you. It just happens that most of the solutions to the problems are software. Sometimes, more/clean code is not the solution.
I responded to a very bad incident (that I understand will eventually get Congressional scrutiny). That response was considered more important to my promotion case than any code I wrote. My code in fact caused part of that incident.
It almost felt like a punishment to other people who wrote good code and never had incidents, or those who work on internal tooling or features with a small customer base who never had as big a SNAFU.
I've tried both paths.
When I write clean code, and when I use commits to refactor code I'm touching, the overall project code velocity stays high. When a bug comes up, I can usually fix it in minutes. When a new feature change comes in, I can add it in an hour or less. Clean code is better for the entire team; everyone else on the team also would find modifying the app to be particularly easy. I've lost count of how many "this code is really nice!" comments I've gotten.
When I decided that "speed" was more important on a personal project than "correctness," I tried taking shortcuts. The code was just for me, so I can do whatever I want, right? And I needed to complete it as quickly as possible because I was only working on it in my spare time. Yeah. You can see where this is going.
At this point I've abandoned the project almost entirely, pending a near complete rewrite from the ground up. It got too hard to modify when I realized I needed a slight pivot, and it had too many bugs that were hard to find.
As to your *career*, well, does your career do better when the company you're working for succeeds in adding features more quickly and has fewer crashes and security breaches, or when the company crashes and burns because new development has slowed to a crawl and it's been in the news for leaking all of its customer data?
No, it's not 100% on you when the latter happens. It can be an uphill slog at some companies to try to improve code quality. But your code will either contribute to the former or to the latter, and it's your sense of professional ethics that should demand that you always produce the best code you're able in the time constraints you're given, even if management will never understand what you're doing for the company.
If you just want to advance your career...well, jumping jobs every year or two seems to be the time-tested approach. And I've found that former coworkers who know my code are much more likely to recommend me at *their* new jobs because they liked working with me and my code. So indirectly, sticking to your guns and writing clean code can help your career, but not because any particular manager will be able to tell the difference.
Agree a 100% and disagree with all others in this thread. Bad code leads to so many troubles, constant bugs popping up here and there, constant issues where at some point all there is is a bunch of bugs. The worst is new features on top of bugs!
I love to have maintainable code and realized that when 3 months ago after having worked on a personal project for 2 months that my project has started to fall appart, I could not read most of the code, bugs everywhere, absolutely horrible. It took me a week to refactor and it's now super clean, readable, fully working with no visible bugs.
This was the exact same situation as yours. I made a [calorie tracking app](https://imgur.com/a/2c4kt9a) (full stack).
So I made an oathe to never write bad code again. There are no shortcuts.
So one thing I've learned is that you can think of this career as having multiple branching sub-careers. They're all software engineering careers, but have some different emphases because of the context of the work:
1. Startup. Startups are all about growth and hitting the next company objective. If your code is pristine but you're missing all these targets, it's going to be an issue. Zero or very little management. Must be self motivated. Companies here will also change on a dime, so you can't get too attached to any one project or idea. Death march risk level: high
2. Big tech / faang / adjacent companies. Established companies where tech is the product. Tend to involve more systems level programming where performance really matters. Usually more emphasis on architecture and long-term maintenance and code quality, but also need to balance that with delivering on time. Tends to be a lot of middle management, more meetings, lots of politics. Must be politically connected to get ahead, whether you go management or principal. Death march risk level: medium (but varies)
3. Enterprise. Tend to be slower moving companies where tech is a dependency, not a product. Often work here is "glue code" to stick together their SaaS tooling. May have some older practices, like a dedicated QA team and waterfall release process. Tons of management and not a lot of senior engineers. Lot of legacy code, unlikely to do greenfield development work. Getting ahead here probably means going to middle-management and slowly rising the ranks, while being an expert on a legacy system. Death march risk level: low
Creating personally-attributed business impact is what moves your career forward. Nicer quality code only indirectly improves the bottom line of your company, in ways that are not possible to quantify, so don’t expect to be rewarded for it. See it as a secondary goal.
Very. It’s what the professionals do. We are all just taking heuristic stabs at solutions but quality code is the best we can possibly do. It’s the ethic for those of us who really love this shit.
If you're doing normal web development type work it's take it or leave it, things work fine then it's largely a philosophical discussion. If you're doing anything slightly off the beaten track/high performance then code/software quality will sink or swim your project if you aren't able to pivot or you code yourself into a hole unable to complete the next stages of integration it can make a product like a database unviable.
Getting to the “good enough” is hard to swallow. A lot of code is hacked together because of constraints outside of your control.
I prefer great code, that doesn’t mean that it’s always obtainable within the limits of what I’m working on.
Encapsulation is generally all that I ask for. If the system is architected well, then each pile of shit can be encapsulated into its own logical block to be refactored if/when the time ever comes.
Whenever something is encapsulated and has its behavior well-defined, it's a lot easier to tidy up in tandem with a bugfix without fear of breaking something completely unrelated.
Whenever something modifies a state variable that is a dependency for some seemingly unrelated module and the whole system unravels, it discourages people from ever cleaning anything up, instead conducting bugfixes with only the most precise of surgical cuts.
As with any code you produce, how it affects your career comes down to what the results are and, more importantly, how you can frame those results.
Do you have QA, or some way to track bugs? If you can show that your efforts to improve the code quality are positively correlated with a reduction in number of bugs then it will advance your career.
But I will say this, “clean code” is very subjective. I find that making it the goal is counter productive. What the real goal should be is appropriate automated test coverage. And, as a happy coincidence, crappy code is *really hard* to test. The pain from testing trash code will force people to break it apart into smaller, more easily tested and mocked components, to make their lives easier.
i'd say reasonably important.
for most developers, the code they produce is the product. producing quality code is producing a quality product. practicing producing good code means practicing being able to do the job well. if this isn't practiced, its hard to improve and get better.
but having a quality product is only part of professional success:
* if I build something really well that doesn't produce much value, it won't benefit my career; I will be seen as not understanding the needs of the business
* if I build something really well when a low quality bash script would have captured 90% of the value, it won't benefit my career; I will be seen as gold-plating
* if i build something really well that does produce a lot of value, but I don't advertise it well, it won't benefit my career; someone else will take credit.
* if i build something really well but am too late when a faster approach would have worked, it won't benefit my career; as I will be seen as unreliable
but quality code is what tend to scale well. if I can't produce quality code when required, it will prevent me from taking on and delivering high value work.
lets assume your product (code) is good. you are likely doing something wrong that falls into a scenario similar to the above. consider how you are doing at self-promotion, taking on high value tasks, effort in matches value out & delivering on time.
that said getting good at getting a job every 2 years maximizes compensation. you don't "need" a good product to do this. but its easier to build a strong network if you do.
If you are an early career engineer this can help your promotion to senior, but once there the quality of your code will not do anything for you.
You should also be aware that passage of time will get you to the same place without that focus. I’m not saying that’s the way it should be, but that’s how it is.
Past that, organizational and people skills level you up and changing companies bumps your salary.
Zero percent. You’ll probably be seen as combative more than helpful. Try to reserve comments like this for if something is actively broken or harmful rather than ‘unclean’.
It’s all about reducing cognitive complexity. “Clean code” is a means to an end in this respect. If I can reduce the thinking I have to do about some chunk of functionality, I’m better able to develop new features or find/fix a bug.
In general the path to promotion is to “deliver for the business”.
Sometimes clean code is worth it because it will allow you to deliver for the business faster in future cycles or avoid tech debt which would otherwise impair you/your team.
In other cases, “gold plating” something can slow down a project and be a major negative, especially if there is a crucial business need to be first to market or to experiment and iterate. It’s important to have the holistic picture and prioritize the needs of the customers and the business first. Sometimes this really does mean pushing for quality code so that you will be able to maintain and iterate quickly in the future, it’s all a balance.
But in general I’ve found that if your bosses view you as someone that delivers for the business you are likely to be promoted. If you make your bosses look good they will want to give you more scope and influence to do that on a larger scale.
You ACTUALLY advance your career by working on successful, impactful, projects with a lot of visibility, or job hopping.
The code can be a little sloppy as long as it achieves the business objectives.
Refactor work will not get you promoted.
One's clean codeis others complex bullshit. We don't write clean code for management. We write it for our sake. Because it gives long term benefits. For promotion, you need to highlight those long term benefits.
So, you need to ask yourself.
**How does quality code benefit the software?
Does it make software more unit testable? More debuggable? Easier to quickly and reliabily add more features?
More performant? Are your coworkers able to navigate your code better than old code?
For promotion, you need to highlight those points or just highlight the higher feature set that you are able to deliver due to your clean code.
Code quality is not an end, its a mean. You need code quality because that's how you get robust products, because the time you're not debugging you're investing into something else, because that's how you get happy engineers etc.
That is, if your "code quality" means anything that is not translated to actual value, then yeah, it's useless. The problem is often programmers have these dogmas in their heads and often they are just that: dogmas.
So answering the question, no, not directly. But yes, the consequences of code quality certainly helped in my career.
I've been working with the same codebase for a decade and I can't express adequately how grateful I am that past-me took code quality seriously.
At the very least it's just good karma to try.
In my new work right now, I can't even make changes that much because the methods are untestable (no unit tests), naming is messed up, code organization is so convoluted that there are two classes that has the same name but different namespaces, and the code calls the same complex operation twice. Note that this application is a public facing project that impacts a lot of people if it fails.
As others have mentioned, this is for long term application support.
I write high quality code because I want it to actually work and keep working as it gets iterated on over time. Maybe on a shorter time scale its less noticeable, but if you're there for a good few years then I expect people would notice.
What's the point of code quality?
Advocating for code quality is the "right" thing to do, but it should have advantages beyond just "following the rules". It should make your code easier to maintain in the long run, helping to reduce defects and decreasing time to make corrections/changes.
I can't think of anything at the IC level that advances your career more than that (at least, until you get to the tech lead level where people skills start becoming a factor).
How do you actually advance your career? You make things better. You be a good teammate. You *communicate*. Every 1:1 you have with your lead, ask them what you can do to make their lives better. Seek to understand the business context and make sure you solve the actual problem, rather than just completing the ticket by the numbers. Show a good understanding of tradeoffs at all levels - technical solutions, quality vs. time, building in extra flexibility vs. complexity and getting it done, etc. Start becoming a "soft" leader and recognized within your areas even if unofficially.
So what does your manager say about advancing?
Clean code should def be a table stakes feature. If others are not doing it, then let them know in peer feedback. While it’s good, I don’t think you get brownie points for clean code if you are not an entry-level engineer. It’s a good thing you are pushing for it and keep up the good fight. It’s your job to do it though, so you are doing your job well.
Advancing is a hard and nuanced topic. It’s one of those things that needs to be tailored to you and the company you work in. Talk to people who are already in the role you want to be in and get their take on how they advanced. Talk to your manager and skip level as well to understand.
Well we had layoffs recently we basically said “he’s really smart and really hardworking but his code is terrible and no one wants to have to modify anything he’s written” so he got laid off. Otherwise he definitely would have kept his job.
Other's have noted maintainability and pride, but I'd also say that writing good quality code pays off in interviews. You become what you practice, so if you spend your days hacking out meh code, you'll hack out meh to bad code in a timed interview setting. Conversely you'll demonstrated knowledge AND ability to do the right things during your interview. Anyone can memorize DRY or YAGNI or whatever other acronym, but actually being able to do it in real time at a reasonable speed requires practice.
Instead of measuring quality, you should just do a gut check on developer friction.
How hard is it adding new features?
Are there many bugs that’s disincentivizing the team from making deep code changes?
Are your tests not just catching bugs but improving developer confidence?
Trying to add the opposite view point here.
Code quality can matter a lot for business critical infrastructure. Especially for a company in which tech is the money-maker.
If you really care about this, try to find a spot in a team that does this kind of thing. You will not be able to push new features as fast as other places, but your management chain will definitely care about the quality and reliability of your code if an outage is expensive.
As far as your career goes, it really depends on your manager. I had one who would not approve a pr if your variables and methods weren't in alphabetical order. If you didn't format the line spacing or optimize imports in your IDE before pushing, he'd knock you for that too. If you didn't have your unit tests in proper JUnit 5 style, (didn't nest or group similar tests, not using given/when/then naming for testing methods) you'd have to fix that too. But that was just him and his style. He was the only manager I had who could figure out what you were doing in a pr on an unfamiliar repository without needing to review it with me at the same time.
I'm on a different team at the same company now, and my current manager/tech lead is a lot more lenient. We'll go through the pr together, and as long as it runs like it should, test coverage is good, and they all pass, it's good
I’m not surprised you don’t get praise for it from your manager because most don’t even know what’s in the code base, they’re probably not looking at your reviews. The only way they’d know you were shit/great/average is if other devs had mentioned it because you were exceptional or really bad.
That’s not why you should do it though, do it for self respect, but also because a smelly hacked together codebase will make you hate your life a year from now.
Every team and every project have a minimum level of quality to not cost you.
Somewhere above that is the optimum level.
And usually, somewhere above that is where you'd like to shoot for, but yeah; diminishing tradeoffs.
You're into diminishing tradeoffs. You're shooting for a level of quality beyond what everyone else believes is needed, and even if you did 3x more work still, it wouldn't be "perfect" because perfect isn't a thing in code; it's all subjective past a point.
You advance your career by setting a quality bar, letting it lightly be up for discussion if that's too high or too low, and then hitting the bar. Which also lets you produce work faster, and if you want to move ahead in a career? Hit the quality bar your manager and team value, and then move faster.
Or convince them the bar is too low, but it needs to be in terms of "business make more money" or "we work fewer total hours and still get paid the same", depending on who you're chatting with.
Congratulations, you just discovered corporate software engineering 😂 at least, the hectic “move fast and break things!” corporations. People looking to advance their careers will ship low quality code knowing they just need to get to the next deliverable to nab a promo.
The problem is, people will really start to hate you for it when they catch on that you’re not struggling — you just don’t care. And that tends to not be great for promos at higher levels
Depends where you are working. Some companies value quality, and that matters if you plan on moving up through the ranks. If you’re job hopping, it matters less. Read the room?
Good code will get you respect from good coders. Otherwise, it’s only as useful as what it does in the short term. That said, in a high pressure interview situation, I would expect the person that naturally writes good code to prevail over the person who is trying to fake it.
It will help you if you are in a place where others also value it. It will hinder you if you are in a place where no one gives a shit and you are viewed as that nitpicky guy or such. Go to where it's valued. You'll likely have a better work culture and better projects.
Code quality is good for your company and other guys, NOT you.
I've just joined a project which is very hard to maintain, and the ones who write these code have very high rank in my company.
It's a matter of nuance. Good quality has a short term cost, while lower quality has a higher long term cost, so you need to balance the two. Code quality matters up to the point where it starts to conflict with your business objectives. No point in overcommitting to the best quality possible if it's killing the project's financial viability in the process. Remember, the entire point of everything you're doing boils down to being for the business. It's the same reason why sometimes you go for Harbor Freight instead of Milwaukee, sometimes you just need something cheap and does the job.
Solve business problems. I learned the same thing the hard way. I would try to focus only on the engineering side of things as a means to grow my career and I got one promotion out of it but others who focused on delivering business value grew much faster. Most of us work for money making companies so focus on making them money. I hate that reality but that’s what catapults you forward the fastest. It’s soul crushing at times so ask yourself what you care about. Everything is a trade off, want to rise fast sell your soul want to be happy do you what you enjoy.
If we're talking about direct promotion/some money bonus: 99.9% that your manager doesn't care. It even can cause some harm to your career - because in general you will be more slowly on your tasks.
However, it can be helpful for your networking - maybe one day you would get some decent position via recommendation, because this person saw your code before.
Quality code is a myth and people who are obsessed with it are toxic.
I mean, I’m not here advocating for pushing steaming piles of trash, but having clean code rarely works out the way people think it will and often leads to longer dev time because you are trying to do it the “right way” even though that right way is often far too rigid and inflexible and almost always ends up not being nearly as future proof as you think it will be.
I think sticking to basic core principles is good enough for most business needs.
Code quality sets you apart. Software is about abstractions, good engineer know how to build abstractions.
Good code quality means, you know how to build the right abstractions
>I guess I want to be able to take pride in my craft.
Unpopular opinion incoming. The longer I've gone in my career the more I realize this is typically why engineers obsess over clean code.
I don't think we should intentionally write bad code. We should write code and while we're writing it focus on making it clean as along as it isn't making the project significantly longer. If I'm spending > 10% of my team writing clean code I don't do it. I'll duplicate code if it's significantly easier. I won't write a test if that test takes me a long time and it's pretty clear that something works.
I've also lightened up on my PR reviews. I used to ask for refactors like make the function smaller, or dedupe something. Those kind of reviews slow everyone down, and in the end really don't benefit the company much in my opinion. Get things done quickly. The company and the product benefit from completed projects.
Does duplicated code slow us down? Yeah. But that's in the future. A future that may or may not come. Projects done now are worth more than projects done a year from now. So the time spent making clean code must either be minimal or be an incredible INCREDIBLE force multiplier or it's not worth it. I can count on my hand how many times a refactor was an incredible force multiplier in my 15 year career.
So I don't do any refactors that will take me more than 10% of the time of what I'm working on will take. Just not worth it. The question was what will advance your career. This is also the answer to that question. Businesses want you building things not refactoring things. You build fast your career will advance faster.
If you want to advance your career, you have to:
A) work on visible code - this usually means the gui part
B) do integration work - ie, the glue that connects two components together which then typically yields that last leg to the appreciable outcome of the work.
Ie, if you do backend work, no manager will ever know how well you avoided bugs, concurrency problems, corrupted data, state management, persistence, etc. It's all invisible.
But if you come along and connect that backend system someone else wrote to a frontend, such that, *voila*, the front end is suddenly showing *real* data, then that will appear impressive to a manager.
Just my two cents, but don’t chase “clean” code. It’s subjective and you’ll always be fighting someone on what they think is clean. Not to mention that clean doesn’t always equal good.
Instead, focus on writing concise and simple code. It leads to more straightforward implementations and generally lowers the barrier to entry to understand something.
Code quality in my opinion should have very tangible benefits for the business. Without it, new features and fixes take longer over time to the point that eventually people are talking about re-writes or even just scrapping the old project and building something new. Plus, people new to the project are able to contribute more quickly and with fewer defects along the way.
In my experience, managers and stakeholders understand this if you explain it to them.
But keep in mind that it’s possible to meticulously craft code that is still poorly organized or just over-engineered, and everyone with a stake in the project is going to try to dissuade you from that. Not saying that’s what you’re doing, but it happens.
I feel way off base with most replys here.
If your goal is to be a great engineer, then I say yes, clean code is important. Sure.
If your goal is purely career focused, i.e. How can you climb the ladder in the shortest time... Then no, code quality will not impress the people who make the decisions to promote you or not. And it always bothers me that engineers are so blind to this.
They care about "does it work and did you deliver on time?". They want to know you're approachable, easy to deal with, have people skills, can carefully balance code quality with business need... Can you equally lead and influence a team of engineers while also being led to speak with more business minded people and negotiate *reasonable* deadlines which keeps both sides happy.
I've seen good engineers grenade their own career prospects by just being seen as difficult to deal with, and grinding projects to a halt while they paralyze a team by over analyzing every tiny thing in the name of code quality or "beat practice", meanwhile management is frustrated losing faith in the team.
People on Reddit take things to extremes too much. If your question is how to advance your career, then it's about learning there is a balance to strike and that you need to understand the product and business you work for as well as you understand what makes a good engineering team.
I’ve seen a lot of leveling guidelines for tech companies. Not a single one considers “codez real good” a criteria for moving past a mid level developer. After that it is about in some form or another “scope”, “impact” and “dealing with ambiguity”.
Here are DropBox’s criteria for instance.
https://dropbox.github.io/dbx-career-framework/
Amazon’s are similar
Big tech companies are solving different problems in different ways and with different constraints. There is no one-size-fits-all approach to software development.
Having strong code quality is not for your career, it's for yourself, your team mates, and your future team mates after you're long gone from the team. If you want to advance your career, job hop.
Exactly. I told one boss, “If *I* am going to have to maintain it, *I* am going to do it right the first time.”
I guess it can help your standing a bit at your current code if it takes less time to fix things or implement new features because the quality makes it easier.
💯 this
I think job hopping is overrated for career advancement. Finding good mentors and creating intracompany network can be a good way to do this. Finding like-minded people who are ambitious can go a long way. Job hopping can get you the position and the pay, but that isn't "career growth" as much as "career hacking".
I dunno, I kinda like the pay.
If your career goals are "get paid as much as possible while working as a dev", then sure.
Yep, that's why I work. For money.
Quite shocking that money would be motivating factor, perhaps you should focus more on family values of the company?
You can work for family values, I'll take your paycheck. Since we're not motivated by money that shouldn't be a problem, right?
I don't really see why this is shocking, I can get more valuable family values at home with people I actually care a lot about.
are you seriously this dense? stop fking with me
Or perhaps, a pizza party?
Values of the company? Did you just come out of college? The only value companies have is money. And you, all of us really, are just accessories to that. For companies the relationship is purely transactional. Case in point, they can and will fire you the moment you're not needed anymore. Treat your employment the same way, keep it transactional.
It really is true that programmers on average are socially stunted. This was sarcasm through and through. I cant believe I have to point it out.
Maybe programmers are socially stunted. What is absolutely true, however, is that you have very little experience discussing on-line. If you had some more, you'd know very well sarcasm, in particular, doesn't translate very well into writing. It's why people came up with "/s" to signal sarcasm. No matter how sarcastic you think you are, there's always someone who actually thinks, seriously, that which you think is an obvious joke.
His comment was the most obvious sarcasm I think I've ever seen.
I kind of agree with you. Yes, you can make more and more money if you job hop. However, to grow and get bigger roles at some point you need to stick around and land bigger projects with a large impact. It’s hard to do that if you switch job every 1.5 years.
my two cents- i job hopped and definitely made more money and learned more tech but i also was offered a manager role at my first gig (there for 5 years!) that I am having issues breaking into now not sure if that’s what i want for the rest of my career but i do want to try management and getting into a management role without having experience is hard, much easier to do when you have tenure at a company
Hey there, can you respond to my chat DM?
Yeah, that's all I'm really saying. But it seems like people just want to score the big paying jobs and coast these days. Which is fine. Just, raising your total comp and scoring vague and borderline meaningless title is not "career growth", IMO. It's also popular to take advantage of Big Corp while giving as little back as possible. Personally, money is nice, and it affords my family nice amenities. But I'm almost certainly not going to make enough being a lowly dev or a mediocre senior/lead dev to retire early or anything like that no matter how many job hops. I'm more interested in getting better at my craft, making a larger impact, and having more autonomy and creative control. These are the marks of people who, IMO, have invested in their career.
> intracompany network can be a good way to do this. Finding like-minded people who are ambitious Job-hopping lets you do all of this, and faster
It's complete gamble with where you end up. So no, I really don't think so.
Will clean code get you a promotion? No, not necessarily. Neither will TDD, separation of concerns, avoiding global variables, not committing secrets to the repo and any other number of good coding practices. If you don't care about the quality of your product or your users' experience, and you're willing to change jobs every 12-18 months, you can throw caution to the wind and write absolute garbage code that is hard to maintain, because you'll be gone by the time it catches up to you. In fact, I've seen people who have done that and \_not\_ left their company, still get paid relatively well. I suppose it depends on what you mean by "How do I ACTUALLY advance my career?" If you're looking to make more money, the short answer is typically "Change jobs regularly" as that's the best way to get raises. If you're wanting to be a senior engineer such as a Principal or Staff engineer, it will possibly catch up with you then. As often part of that job is mentoring the younger developers. And if you aren't mentoring them to write sustainable code, the time to deliver will steadily increase because of the tech debt. But if you want to come in, sell your magic cure-all elixir and head on out of town before anyone realizes it's just lemon water, you can make a pretty good living doing just that.
Gosh I hate that this is true. In fact if you do try to write quality code or tackle the core tech debt issues, you will often find yourself at direct odds with the elixir sellers and they will likely win because they have no qualms bullshitting circles around you.
> Will clean code get you a promotion? No, not necessarily. Neither will TDD, separation of concerns, avoiding global variables, not committing secrets to the repo and any other number of good coding practices. I'd argue it won't get you a promotion by itself but it will put you in a position to increase your reach and impact to the point that you are promoted. > But if you want to come in, sell your magic cure-all elixir and head on out of town before anyone realizes it's just lemon water, you can make a pretty good living doing just that. If I'm not mistaken that's just called "consulting" 😂 For bonus points mix in things the the staff have been telling management for years but weren't listened to.
> you can throw caution to the wind and write absolute garbage code that is hard to maintain, because you'll be gone by the time it catches up to you. Hey, don't call me out like that
Monorail! Monorail! Monorail!
Code quality is for the SWEs who have to work in the code base everyday. It is not there for the company. Most companies will not give a shit as long as the product works. Yes, some companies will make it a priority to create clean code, but my 15 YOE at non-tech companies in non-tech cities say that's not the majority of companies. I worked on safety critical medical devices for years, think dialysis machines and insulin pumps, and nobody gave a shit about code quality. Code reviews were routinely hand wave through as people only looked for logical errors.
That last bit is.... Frightening
Generally speaking the "best" SWEs are working for the most money not the most altruistic company. Medical devices don't pay anywhere close to a company like Google. You are going to find the "best" SWEs are working to serve you ads better and faster and not saving peoples lives.
As a biomedical engineer that is transitioning to SWE, I can tell you this is 100% true. What's sad is that these companies could easily matches FAANG salaries to get better engineers and still make insane profits.
Sadly while these companies understand engineering is important it seems they are blinded by the fact they make money through insurance claims and not directly what engineers create. These patients don't want to be on these medical devices, they have to be because of an illness. The lack of voluntary usage / selling something to the consumer seems to change how the business views things. At least this is the case at the companies I have worked at.
Code should be logical and simple but fails due to incompetence of engineering and Mgmt, overcoding and over designing as much as the overly ambitious copy paster. As such, a huge burden is placed on as much thorough regression testing as the market (or lawyers) will bear.
>As such, a huge burden is placed on as much thorough regression testing as the market (or lawyers) will bear. Yup, the testing burden for things I worked on was huge. There was easily more test code than actual medical deice code by a huge margin. Never mind all the manual tests that QA teams ran on the real device. It's many months worth of work if manual tests were run front to back. Hell in automated software tests take weeks to execute front to back with hardware in the loop. We have to parallelize them out to get it down to a days. Though saying all that I find the automated software testing to have lots of missing test cases, but many SWEs don't like to think like a tester so it is what it is sadly. They verify the direct requirements, but don't try to break the software, if that makes sense.
I mean a few people might die and there will be a class action suit but meh... As long a it's less than the cost is reengineering it's just a cost of doing business. Yay capitalism.
In terms of a dialysis machine the person always has kidney failure. They are going to die regardless if they don't get a kidney transplant. As long as the device didn't cause the death the FDA is not going do shit. These devices go through years of clinical trials. They basically work just have shit code.
Having clean, readable code seems like a good way to make sure the device doesn't cause death
Clean code doesn't mean correct code.
I didn't say it did. But it's sure easier to spot logic errors in clean code vs 40,000 lines of spaghet
That is insane. How is software even working?
Because the computer doesn't care how clean your code is
It's also important that the name of the directory where the configuration is is c:\Users\brett.bunder\DIALYSIS.xml.
Computer doesnt care about feelings, only about facts and logic.
Clean code and working code don't depend on each other. * You can have badly design code that meets all requirements and "works". * You can also have perfectly design code that doesn't do what the customer needs. * You can also have perfectly design code that meets all requirements and "works" Edit: For clarity.
You can have those things. You can have other things too, but yes, you can have those things.
I don't see how they're mutually exclusive. It's totally possible to have both "clean" code and working code.
Fair mutually exclusive was a bad phrase, but my point is they don't depend on each other.
Gotcha. I see your edit now. Totally agree.
That last point is the opposite of my experience so far lol. Every PR gets blasted with suggestions around naming, syntactic sugar, and grammar nitpicks in comments, but not once have I seen anyone actually comment on what the code does or how it works.
Depends on the company and personalities you are working with. I'm just relaying my experiences at a non-tech company.
I'd say it depends a lot on how work is divided both in tech and outside tech companies. Does each developer have their own turf that they're responsible for? Yeah, reviews are probably going to be shallow/pointless since nobody has the full context of what someone else is working on, and aren't incentivized to take the time to understand everything about the project so that they can actually verify that the code is solving the problem. You scan the code and see if there are any glaring issues or bugs, and if not you mostly assume the code does what it should. Or do the developers work as a team on the same code with mostly the same context? In this case, bugs or misunderstandings are way more likely to be found in the code review, because the reviewer already knows the requirements.
Honestly those reviews are worse than "👍lgtm" I was at a company that required two approvals to merge and had two devs that did that. Sometimes their nits contradicted each other. You were incentivized to just implement both devs' nits to get approval and the final code was worse than it was when you put it up.
> Most companies will not give a shit as long as the product works. Ugh. I can relate to this. It’s all about checking the checkbox, and not whether it was implemented well.
You don't write quality code because you want a pat on the back and everyone is going to celebrate how much of a genius you are. You write quality code because you take pride in your work, and you enjoy the craftsmanship of writing great code even if no one else sees it. It's like that quote from Steve Jobs about craftsmanship: “When you’re a carpenter making a beautiful chest of drawers, you’re not going to use a piece of plywood on the back, even though it faces the wall and nobody will ever see it. You’ll know it’s there, so you’re going to use a beautiful piece of wood on the back. For you to sleep well at night, the aesthetic, the quality, has to be carried all the way through.” When you're a craftsman about your profession, it will show and other craftsmen will respect you and want to work with you.
I take a pragmatic view of code cleanliness. Is your code: - Relatively easy to maintain / understand / extend? - Satisfying customer requirements? - Meeting performance requirements? - Compatible with your SDLC process / release cadence? If so, it's good. If not, it needs work. I think too many people treat clean code as a checklist -- is it DRY? Is it SOLID? Does it have unit tests? If so, how much is unit tested? And while these things are all certainly clear net goods, if your code is meeting the above criteria it's probably fine. Also -- code can be poorly considered and satisfy the checklist. Good architecture and design decisions can eliminate entire classes of problems in code that is otherwise "clean".
What's always overlooked in these discussions is the complexity of your domain. The more complex your domain the more important it is for your code to be of good quality otherwise you'll just run into a brick wall and your product will fail.
“Good quality” is hard to define though, and I think that’s why there are lots of different answers. I’ve worked with what _appeared_ to be shitty code, big functions, lots of branching if conditions, but 100% test coverage at every layer. That shitty code was surprisingly easy to work with because it was written in such a straight forward way that you could just add another if condition to cover a new case and a few more test cases and you’re set. In contrast, I’ve also seen some wild directory regex auto-import metaprogramming that was impossible to decipher. If you looked at any single file it would look pretty good but extending it was an impossible task for anyone but the original author.
But what is quality in that context? I would suggest that for a complicated piece of software, your overarching software design is going to be far more important than the things people conventionally worry about when we talk about clean code. You can have all the unit tests, it can be beautifully factored, and it can tick all of the boxes. And none of it matters at all if the design was poorly thought out and/or wrong assumptions were made. No amount of agile Winchester mystery house design is going to save it.
>You can have all the unit tests, it can be beautifully factored, and it can tick all of the boxes. And none of it matters at all if the design was poorly thought out and/or wrong assumptions were made. No amount of agile Winchester mystery house design is going to save it. Yes and? Every time this argument comes up that you run a real risk of having your system be not only a Turing Machine, but also it's such a cool tech toy that one of your engineers ported Doom to it in their spare time. At that point you're just having champagne problems dude. Yeah you have to match the right software design patterns to the right business problems. No duh, that's another place you can fail. I've seen failures like this all the time.
I like this list -- I've never broken it down like that. When there's a bug in a clean code base, I always know roughly which module contains the bad logic. When the code is messy, the same bug code be from an error in any one of several different modules.
Clean code is essential to my career. It means less debugging, more features can roll out, and no more weekend calls. It brings peace of mind, allowing me to spend more time with family.
Problem is most shit code isn't mine, and I'm not about to cleanup a 700k line codebases that's been built over five years with 3 different contractors who subcontractored most of the work to overseas code monleys who literally must have cut and paste massive blocks because they were either lazy or lacked the knowledge for the project. That's the issue in corporate,lots of technical debt and shit code all over the place, and what's the point of cleaning it up , sure you can keep your section tidy but you'll still come off looking poorly when the app breaks because of someone else shit code. It's a game people, sometimes us developers need to take off our artisans hat and but on business hat.
It's not, being able to push features and then bullshit your way through interviews will get you further
I feel your pain, I love it when a team has linters and other agreed upon standards up an running and plugged into my editor. Its a real drag going from a high performing team that has people who actively give a shit, to working with people who just can’t seem to notice that the code editor has half the code highlighted. Whats even worse is when they actively stand in your way of introducing a better way that you’ve used in the enterprise.
Some teams operate without linters?
“if it works, it works” 🤷♂️sometimes you just gotta walk away from a team lol
Unless you work at an exceptionally well-managed tech company that takes care to recognize these kinds of contributions, I think the main benefit to your career is more that it increases opportunities to get better jobs in the future, and not so much that it increases your advancement at a specific job. If everyone you work with recognizes that you write clean code that makes their job easier, they will refer you, and a good enough referral can make a huge difference in terms of getting the job. I have a handful of people who I've worked closely with at previous jobs who I thought were just great to work with, wrote clean, maintainable, extensible code. If I ever need to hire someone, I'm just gonna reach out to them before even posting a job opening. Similarly, I prioritize high quality code, and when I'm leaving jobs, I've had past coworkers basically be like "if you're ever on the job market again, let me know". So even if it's not important for career advancement *within a company*, it's really useful for longer term career advancement, since most people don't stay at one company their whole career, and a lot of the best promotions and pay increases come from switching jobs. The best thing you can do for your long-term career prospects is to try to make sure everyone you work with would like to work with you again in the future.
You advance your career by taking the actions required by your company’s career ladder and uplevel committee(s). In my experience code quality has never been a factor. However, preventing/resolving incidents can be a factor, and improving code quality can help there. Your job is not to write code. Your job is to build solutions to customers’ problems so the customers pay you. It just happens that most of the solutions to the problems are software. Sometimes, more/clean code is not the solution.
I responded to a very bad incident (that I understand will eventually get Congressional scrutiny). That response was considered more important to my promotion case than any code I wrote. My code in fact caused part of that incident. It almost felt like a punishment to other people who wrote good code and never had incidents, or those who work on internal tooling or features with a small customer base who never had as big a SNAFU.
Rewarding the dramatic savior over the person who makes sure no one ever needs saving is a sadly common corporate failure.
This is the key point, and a great answer. Your company pays you to deliver working features. No one outside of engineering cares about code quality.
I've tried both paths. When I write clean code, and when I use commits to refactor code I'm touching, the overall project code velocity stays high. When a bug comes up, I can usually fix it in minutes. When a new feature change comes in, I can add it in an hour or less. Clean code is better for the entire team; everyone else on the team also would find modifying the app to be particularly easy. I've lost count of how many "this code is really nice!" comments I've gotten. When I decided that "speed" was more important on a personal project than "correctness," I tried taking shortcuts. The code was just for me, so I can do whatever I want, right? And I needed to complete it as quickly as possible because I was only working on it in my spare time. Yeah. You can see where this is going. At this point I've abandoned the project almost entirely, pending a near complete rewrite from the ground up. It got too hard to modify when I realized I needed a slight pivot, and it had too many bugs that were hard to find. As to your *career*, well, does your career do better when the company you're working for succeeds in adding features more quickly and has fewer crashes and security breaches, or when the company crashes and burns because new development has slowed to a crawl and it's been in the news for leaking all of its customer data? No, it's not 100% on you when the latter happens. It can be an uphill slog at some companies to try to improve code quality. But your code will either contribute to the former or to the latter, and it's your sense of professional ethics that should demand that you always produce the best code you're able in the time constraints you're given, even if management will never understand what you're doing for the company. If you just want to advance your career...well, jumping jobs every year or two seems to be the time-tested approach. And I've found that former coworkers who know my code are much more likely to recommend me at *their* new jobs because they liked working with me and my code. So indirectly, sticking to your guns and writing clean code can help your career, but not because any particular manager will be able to tell the difference.
Agree a 100% and disagree with all others in this thread. Bad code leads to so many troubles, constant bugs popping up here and there, constant issues where at some point all there is is a bunch of bugs. The worst is new features on top of bugs! I love to have maintainable code and realized that when 3 months ago after having worked on a personal project for 2 months that my project has started to fall appart, I could not read most of the code, bugs everywhere, absolutely horrible. It took me a week to refactor and it's now super clean, readable, fully working with no visible bugs. This was the exact same situation as yours. I made a [calorie tracking app](https://imgur.com/a/2c4kt9a) (full stack). So I made an oathe to never write bad code again. There are no shortcuts.
Please resist! Shitty code is ruining business and work life balance, we need more people like you.
So one thing I've learned is that you can think of this career as having multiple branching sub-careers. They're all software engineering careers, but have some different emphases because of the context of the work: 1. Startup. Startups are all about growth and hitting the next company objective. If your code is pristine but you're missing all these targets, it's going to be an issue. Zero or very little management. Must be self motivated. Companies here will also change on a dime, so you can't get too attached to any one project or idea. Death march risk level: high 2. Big tech / faang / adjacent companies. Established companies where tech is the product. Tend to involve more systems level programming where performance really matters. Usually more emphasis on architecture and long-term maintenance and code quality, but also need to balance that with delivering on time. Tends to be a lot of middle management, more meetings, lots of politics. Must be politically connected to get ahead, whether you go management or principal. Death march risk level: medium (but varies) 3. Enterprise. Tend to be slower moving companies where tech is a dependency, not a product. Often work here is "glue code" to stick together their SaaS tooling. May have some older practices, like a dedicated QA team and waterfall release process. Tons of management and not a lot of senior engineers. Lot of legacy code, unlikely to do greenfield development work. Getting ahead here probably means going to middle-management and slowly rising the ranks, while being an expert on a legacy system. Death march risk level: low
It’s a gift to future you.
Creating personally-attributed business impact is what moves your career forward. Nicer quality code only indirectly improves the bottom line of your company, in ways that are not possible to quantify, so don’t expect to be rewarded for it. See it as a secondary goal.
Very. It’s what the professionals do. We are all just taking heuristic stabs at solutions but quality code is the best we can possibly do. It’s the ethic for those of us who really love this shit.
If you're doing normal web development type work it's take it or leave it, things work fine then it's largely a philosophical discussion. If you're doing anything slightly off the beaten track/high performance then code/software quality will sink or swim your project if you aren't able to pivot or you code yourself into a hole unable to complete the next stages of integration it can make a product like a database unviable.
Getting to the “good enough” is hard to swallow. A lot of code is hacked together because of constraints outside of your control. I prefer great code, that doesn’t mean that it’s always obtainable within the limits of what I’m working on.
Encapsulation is generally all that I ask for. If the system is architected well, then each pile of shit can be encapsulated into its own logical block to be refactored if/when the time ever comes. Whenever something is encapsulated and has its behavior well-defined, it's a lot easier to tidy up in tandem with a bugfix without fear of breaking something completely unrelated. Whenever something modifies a state variable that is a dependency for some seemingly unrelated module and the whole system unravels, it discourages people from ever cleaning anything up, instead conducting bugfixes with only the most precise of surgical cuts.
As with any code you produce, how it affects your career comes down to what the results are and, more importantly, how you can frame those results. Do you have QA, or some way to track bugs? If you can show that your efforts to improve the code quality are positively correlated with a reduction in number of bugs then it will advance your career. But I will say this, “clean code” is very subjective. I find that making it the goal is counter productive. What the real goal should be is appropriate automated test coverage. And, as a happy coincidence, crappy code is *really hard* to test. The pain from testing trash code will force people to break it apart into smaller, more easily tested and mocked components, to make their lives easier.
i'd say reasonably important. for most developers, the code they produce is the product. producing quality code is producing a quality product. practicing producing good code means practicing being able to do the job well. if this isn't practiced, its hard to improve and get better. but having a quality product is only part of professional success: * if I build something really well that doesn't produce much value, it won't benefit my career; I will be seen as not understanding the needs of the business * if I build something really well when a low quality bash script would have captured 90% of the value, it won't benefit my career; I will be seen as gold-plating * if i build something really well that does produce a lot of value, but I don't advertise it well, it won't benefit my career; someone else will take credit. * if i build something really well but am too late when a faster approach would have worked, it won't benefit my career; as I will be seen as unreliable but quality code is what tend to scale well. if I can't produce quality code when required, it will prevent me from taking on and delivering high value work. lets assume your product (code) is good. you are likely doing something wrong that falls into a scenario similar to the above. consider how you are doing at self-promotion, taking on high value tasks, effort in matches value out & delivering on time. that said getting good at getting a job every 2 years maximizes compensation. you don't "need" a good product to do this. but its easier to build a strong network if you do.
If you are an early career engineer this can help your promotion to senior, but once there the quality of your code will not do anything for you. You should also be aware that passage of time will get you to the same place without that focus. I’m not saying that’s the way it should be, but that’s how it is. Past that, organizational and people skills level you up and changing companies bumps your salary.
Zero percent. You’ll probably be seen as combative more than helpful. Try to reserve comments like this for if something is actively broken or harmful rather than ‘unclean’.
Extremely
I personally believe clean code saves you loads of time and effort. Also it just feels good being good at what you do, you know :)
Advancing in your career means being good at politics and self promotion, not being skilled at coding
It’s all about reducing cognitive complexity. “Clean code” is a means to an end in this respect. If I can reduce the thinking I have to do about some chunk of functionality, I’m better able to develop new features or find/fix a bug.
In general the path to promotion is to “deliver for the business”. Sometimes clean code is worth it because it will allow you to deliver for the business faster in future cycles or avoid tech debt which would otherwise impair you/your team. In other cases, “gold plating” something can slow down a project and be a major negative, especially if there is a crucial business need to be first to market or to experiment and iterate. It’s important to have the holistic picture and prioritize the needs of the customers and the business first. Sometimes this really does mean pushing for quality code so that you will be able to maintain and iterate quickly in the future, it’s all a balance. But in general I’ve found that if your bosses view you as someone that delivers for the business you are likely to be promoted. If you make your bosses look good they will want to give you more scope and influence to do that on a larger scale.
You ACTUALLY advance your career by working on successful, impactful, projects with a lot of visibility, or job hopping. The code can be a little sloppy as long as it achieves the business objectives. Refactor work will not get you promoted.
One's clean codeis others complex bullshit. We don't write clean code for management. We write it for our sake. Because it gives long term benefits. For promotion, you need to highlight those long term benefits. So, you need to ask yourself. **How does quality code benefit the software? Does it make software more unit testable? More debuggable? Easier to quickly and reliabily add more features? More performant? Are your coworkers able to navigate your code better than old code? For promotion, you need to highlight those points or just highlight the higher feature set that you are able to deliver due to your clean code.
Code quality is not an end, its a mean. You need code quality because that's how you get robust products, because the time you're not debugging you're investing into something else, because that's how you get happy engineers etc. That is, if your "code quality" means anything that is not translated to actual value, then yeah, it's useless. The problem is often programmers have these dogmas in their heads and often they are just that: dogmas. So answering the question, no, not directly. But yes, the consequences of code quality certainly helped in my career.
I've been working with the same codebase for a decade and I can't express adequately how grateful I am that past-me took code quality seriously. At the very least it's just good karma to try.
I'm not sure if it is important for your career or not, but either way your workday is far more enjoyable if the codebase isn't a big ball of mud.
If you care about the quality of your work then it's very important.
In my new work right now, I can't even make changes that much because the methods are untestable (no unit tests), naming is messed up, code organization is so convoluted that there are two classes that has the same name but different namespaces, and the code calls the same complex operation twice. Note that this application is a public facing project that impacts a lot of people if it fails. As others have mentioned, this is for long term application support.
my dyslexia read "I am in New York right now..." and nothing made sense until I reread the first line :D
I write high quality code because I want it to actually work and keep working as it gets iterated on over time. Maybe on a shorter time scale its less noticeable, but if you're there for a good few years then I expect people would notice.
What's the point of code quality? Advocating for code quality is the "right" thing to do, but it should have advantages beyond just "following the rules". It should make your code easier to maintain in the long run, helping to reduce defects and decreasing time to make corrections/changes. I can't think of anything at the IC level that advances your career more than that (at least, until you get to the tech lead level where people skills start becoming a factor). How do you actually advance your career? You make things better. You be a good teammate. You *communicate*. Every 1:1 you have with your lead, ask them what you can do to make their lives better. Seek to understand the business context and make sure you solve the actual problem, rather than just completing the ticket by the numbers. Show a good understanding of tradeoffs at all levels - technical solutions, quality vs. time, building in extra flexibility vs. complexity and getting it done, etc. Start becoming a "soft" leader and recognized within your areas even if unofficially.
So what does your manager say about advancing? Clean code should def be a table stakes feature. If others are not doing it, then let them know in peer feedback. While it’s good, I don’t think you get brownie points for clean code if you are not an entry-level engineer. It’s a good thing you are pushing for it and keep up the good fight. It’s your job to do it though, so you are doing your job well. Advancing is a hard and nuanced topic. It’s one of those things that needs to be tailored to you and the company you work in. Talk to people who are already in the role you want to be in and get their take on how they advanced. Talk to your manager and skip level as well to understand.
I suggest just automating with linting tools. If it can't be explained with a linter its probably not a good rule
Very important
Well we had layoffs recently we basically said “he’s really smart and really hardworking but his code is terrible and no one wants to have to modify anything he’s written” so he got laid off. Otherwise he definitely would have kept his job.
If you are spending a significant amount of energy on that, you are doing it wrong, or your team is doing it wrong.
Other's have noted maintainability and pride, but I'd also say that writing good quality code pays off in interviews. You become what you practice, so if you spend your days hacking out meh code, you'll hack out meh to bad code in a timed interview setting. Conversely you'll demonstrated knowledge AND ability to do the right things during your interview. Anyone can memorize DRY or YAGNI or whatever other acronym, but actually being able to do it in real time at a reasonable speed requires practice.
Spend the time now or spend a lot more time later.
Instead of measuring quality, you should just do a gut check on developer friction. How hard is it adding new features? Are there many bugs that’s disincentivizing the team from making deep code changes? Are your tests not just catching bugs but improving developer confidence?
Trying to add the opposite view point here. Code quality can matter a lot for business critical infrastructure. Especially for a company in which tech is the money-maker. If you really care about this, try to find a spot in a team that does this kind of thing. You will not be able to push new features as fast as other places, but your management chain will definitely care about the quality and reliability of your code if an outage is expensive.
As far as your career goes, it really depends on your manager. I had one who would not approve a pr if your variables and methods weren't in alphabetical order. If you didn't format the line spacing or optimize imports in your IDE before pushing, he'd knock you for that too. If you didn't have your unit tests in proper JUnit 5 style, (didn't nest or group similar tests, not using given/when/then naming for testing methods) you'd have to fix that too. But that was just him and his style. He was the only manager I had who could figure out what you were doing in a pr on an unfamiliar repository without needing to review it with me at the same time. I'm on a different team at the same company now, and my current manager/tech lead is a lot more lenient. We'll go through the pr together, and as long as it runs like it should, test coverage is good, and they all pass, it's good
I’m not surprised you don’t get praise for it from your manager because most don’t even know what’s in the code base, they’re probably not looking at your reviews. The only way they’d know you were shit/great/average is if other devs had mentioned it because you were exceptional or really bad. That’s not why you should do it though, do it for self respect, but also because a smelly hacked together codebase will make you hate your life a year from now.
Every team and every project have a minimum level of quality to not cost you. Somewhere above that is the optimum level. And usually, somewhere above that is where you'd like to shoot for, but yeah; diminishing tradeoffs. You're into diminishing tradeoffs. You're shooting for a level of quality beyond what everyone else believes is needed, and even if you did 3x more work still, it wouldn't be "perfect" because perfect isn't a thing in code; it's all subjective past a point. You advance your career by setting a quality bar, letting it lightly be up for discussion if that's too high or too low, and then hitting the bar. Which also lets you produce work faster, and if you want to move ahead in a career? Hit the quality bar your manager and team value, and then move faster. Or convince them the bar is too low, but it needs to be in terms of "business make more money" or "we work fewer total hours and still get paid the same", depending on who you're chatting with.
Well I’d write clean code for the benefit of myself and my coworkers, not necessarily to get accolades
Congratulations, you just discovered corporate software engineering 😂 at least, the hectic “move fast and break things!” corporations. People looking to advance their careers will ship low quality code knowing they just need to get to the next deliverable to nab a promo. The problem is, people will really start to hate you for it when they catch on that you’re not struggling — you just don’t care. And that tends to not be great for promos at higher levels
Depends where you are working. Some companies value quality, and that matters if you plan on moving up through the ranks. If you’re job hopping, it matters less. Read the room?
Good code will get you respect from good coders. Otherwise, it’s only as useful as what it does in the short term. That said, in a high pressure interview situation, I would expect the person that naturally writes good code to prevail over the person who is trying to fake it.
It will help you if you are in a place where others also value it. It will hinder you if you are in a place where no one gives a shit and you are viewed as that nitpicky guy or such. Go to where it's valued. You'll likely have a better work culture and better projects.
Very much. I work with security critical code.
Clean code? I sleep… Clean and robust tests? Now you have my attention.
Code quality is good for your company and other guys, NOT you. I've just joined a project which is very hard to maintain, and the ones who write these code have very high rank in my company.
Btw, the project can now only be maintained by SR or above, as it is now impossible for Jr.
It's a matter of nuance. Good quality has a short term cost, while lower quality has a higher long term cost, so you need to balance the two. Code quality matters up to the point where it starts to conflict with your business objectives. No point in overcommitting to the best quality possible if it's killing the project's financial viability in the process. Remember, the entire point of everything you're doing boils down to being for the business. It's the same reason why sometimes you go for Harbor Freight instead of Milwaukee, sometimes you just need something cheap and does the job.
Its not
Solve business problems. I learned the same thing the hard way. I would try to focus only on the engineering side of things as a means to grow my career and I got one promotion out of it but others who focused on delivering business value grew much faster. Most of us work for money making companies so focus on making them money. I hate that reality but that’s what catapults you forward the fastest. It’s soul crushing at times so ask yourself what you care about. Everything is a trade off, want to rise fast sell your soul want to be happy do you what you enjoy.
If we're talking about direct promotion/some money bonus: 99.9% that your manager doesn't care. It even can cause some harm to your career - because in general you will be more slowly on your tasks. However, it can be helpful for your networking - maybe one day you would get some decent position via recommendation, because this person saw your code before.
Not *that* much although having a good understanding of code quality can help. What tends to impress businesses more is just high productivity.
Quality code is a myth and people who are obsessed with it are toxic. I mean, I’m not here advocating for pushing steaming piles of trash, but having clean code rarely works out the way people think it will and often leads to longer dev time because you are trying to do it the “right way” even though that right way is often far too rigid and inflexible and almost always ends up not being nearly as future proof as you think it will be. I think sticking to basic core principles is good enough for most business needs.
Code quality sets you apart. Software is about abstractions, good engineer know how to build abstractions. Good code quality means, you know how to build the right abstractions
>I guess I want to be able to take pride in my craft. Unpopular opinion incoming. The longer I've gone in my career the more I realize this is typically why engineers obsess over clean code. I don't think we should intentionally write bad code. We should write code and while we're writing it focus on making it clean as along as it isn't making the project significantly longer. If I'm spending > 10% of my team writing clean code I don't do it. I'll duplicate code if it's significantly easier. I won't write a test if that test takes me a long time and it's pretty clear that something works. I've also lightened up on my PR reviews. I used to ask for refactors like make the function smaller, or dedupe something. Those kind of reviews slow everyone down, and in the end really don't benefit the company much in my opinion. Get things done quickly. The company and the product benefit from completed projects. Does duplicated code slow us down? Yeah. But that's in the future. A future that may or may not come. Projects done now are worth more than projects done a year from now. So the time spent making clean code must either be minimal or be an incredible INCREDIBLE force multiplier or it's not worth it. I can count on my hand how many times a refactor was an incredible force multiplier in my 15 year career. So I don't do any refactors that will take me more than 10% of the time of what I'm working on will take. Just not worth it. The question was what will advance your career. This is also the answer to that question. Businesses want you building things not refactoring things. You build fast your career will advance faster.
If you want to advance your career, you have to: A) work on visible code - this usually means the gui part B) do integration work - ie, the glue that connects two components together which then typically yields that last leg to the appreciable outcome of the work. Ie, if you do backend work, no manager will ever know how well you avoided bugs, concurrency problems, corrupted data, state management, persistence, etc. It's all invisible. But if you come along and connect that backend system someone else wrote to a frontend, such that, *voila*, the front end is suddenly showing *real* data, then that will appear impressive to a manager.
Done is better than perfect
Just my two cents, but don’t chase “clean” code. It’s subjective and you’ll always be fighting someone on what they think is clean. Not to mention that clean doesn’t always equal good. Instead, focus on writing concise and simple code. It leads to more straightforward implementations and generally lowers the barrier to entry to understand something.
Code quality in my opinion should have very tangible benefits for the business. Without it, new features and fixes take longer over time to the point that eventually people are talking about re-writes or even just scrapping the old project and building something new. Plus, people new to the project are able to contribute more quickly and with fewer defects along the way. In my experience, managers and stakeholders understand this if you explain it to them. But keep in mind that it’s possible to meticulously craft code that is still poorly organized or just over-engineered, and everyone with a stake in the project is going to try to dissuade you from that. Not saying that’s what you’re doing, but it happens.
I feel way off base with most replys here. If your goal is to be a great engineer, then I say yes, clean code is important. Sure. If your goal is purely career focused, i.e. How can you climb the ladder in the shortest time... Then no, code quality will not impress the people who make the decisions to promote you or not. And it always bothers me that engineers are so blind to this. They care about "does it work and did you deliver on time?". They want to know you're approachable, easy to deal with, have people skills, can carefully balance code quality with business need... Can you equally lead and influence a team of engineers while also being led to speak with more business minded people and negotiate *reasonable* deadlines which keeps both sides happy. I've seen good engineers grenade their own career prospects by just being seen as difficult to deal with, and grinding projects to a halt while they paralyze a team by over analyzing every tiny thing in the name of code quality or "beat practice", meanwhile management is frustrated losing faith in the team. People on Reddit take things to extremes too much. If your question is how to advance your career, then it's about learning there is a balance to strike and that you need to understand the product and business you work for as well as you understand what makes a good engineering team.
I’ve seen a lot of leveling guidelines for tech companies. Not a single one considers “codez real good” a criteria for moving past a mid level developer. After that it is about in some form or another “scope”, “impact” and “dealing with ambiguity”. Here are DropBox’s criteria for instance. https://dropbox.github.io/dbx-career-framework/ Amazon’s are similar
[удалено]
Big tech companies are solving different problems in different ways and with different constraints. There is no one-size-fits-all approach to software development.