These people don’t last long and I have gotten pretty good at screening out this personality in interviews after having it cause huge issues at two different places I worked.
I'll say things like, "I would have done that like this because of this reason, but as long as it works"
or "This needs to change right now because it's a security hole"
or "We should find a more efficient way to do this, because as the data fills up, the users will start to notice it"
I am definitely harder on new people, and people who ask me for help when they should have been able to figure it out on their own.
As a rule, so far throughout my 5 year career as a full stack web developer, my coworkers have neither understood or cared about what clean code entails.
I don't berate, I don't criticize, I've taken to mentioning it once and then doing my utmost to never mention it again in an attempt to avoid labeling myself as the odd one out.
Granted, I've turned down a handful of much higher paying (and presumably higher quality teams) for various reasons. At first, it was because I was a bootcamper and high paying jobs are difficult to pick up out of the gate without the appropriate piece of paper. Since then, I've worked for various organizations on a consulting basis, and most recently landed at an early stage YC startup. Pay isn't great, but I have aspirations to start my own startup, so I'm cool with the pay cut for now in return for the opportunity to learn the ropes, business wise. Founder knows what he's doing at least.
But the devs, man. They just don't care. 500-1500 line React function components are the norm. No standardized way for retrieving data from the back-end. I dread assignments that require me to modify or otherwise integrate with previously written code, because the best way I can come up with to figure out what the fuck is going on is to rewrite it sanely. I'm being a little hyperbolic, I do my best to avoid rewriting wherever possible, but I'm not mis-characterizing things by much.
It's honestly depressing, especially considering I've had multiple other teams offer triple what I'm making right now, but neither of them were pre-seed startup SAAS companies which this one is, so here I stay for the time being.
Invariably, I garner a reputation as "that guy" on any team I work on, although granted this is only the second multi-dev team I've ever worked on. Still though, it feels terrible to get a bad reputation for writing good code. Founder likes my work ethic and output though, so I guess I've got that going for me.
Apologies if this turned into a bit of a rant, it just started pouring out, ha!
It does seem to be something the big co. interview gauntlet is designed to weed out, whether it's worth it or not. I'm sure it's still relatively common, but probably a lot rarer than at the median startup.
You sound still early career enough that the years will likely mellow you out and teach you to better appreciate the ups and downs of building things fast.
You know what’s worse than no abstractions? The wrong abstractions.
I dread cleaning up solutions that I designed earlier where with hindsight, I made a lot of wrong assumptions. I still make wrong assumptions today, they are just designed less brittle.
However one thing I have learnt is more coupled the code is with no or poor incomplete abstractions less likely anyone is going to change it.
In the interest of shipping fast I would rather have some abstraction today rather than none, simply because nobody fixes spaghetti code which is already working.
Building new things start slowing down more and mode and you end up taking weeks for what should have been an afternoon's effort .
There are no right answers, however sometimes wrong abstractions can be marginally better than none.
You know what's worse than the wrong abstractions? Copy and pasting your inline-styled div with a zIndex of 99,999 for the fifth modal in a row because you can't be assed to write a damned display component in anticipation of the next time you'll need to put a Modal together.
Levels to it all. Keep track of painful modules and have strong intent to fix them. Prioritization is a mf.
> But the devs, man. They just don't care.
Well, maybe. Or they just don't know how to write better code.
Either way, the bigger problem is the team management that allows this.
> I do my best to avoid rewriting wherever possible
Why not? If the other devs truly don't care, you could take it upon yourself to clean up the code base little by little when you can.
I used to do this simply because it makes the code difficult to read for me to review if for nothing else.
Linters and style check tools only go so far, and bottom line is you have to ship software not write complex and expensive to maintain tooling, so automation beyond a point is not a solution.
The devs ended up relying on me as the their clean up guy for all the code all the time. I also becoming gatekeeper/bottleneck of sorts.
It is used make blame and dissection more difficult as more times than not I had cleaned up the code and the last one or two commits are mine.
Also the time spent in reviews reduce and you tend to miss important things as you have focused on what should be basic hygiene so much.
One of the reasons I contribute a lot less to production code is this. It is a losing battle if most devs don't care about it as much as you .
Even now the occasional pull request I would make would be peppered with such corrections , it is just automatic reflex for me, but it doesn't make that much difference.
Don't do this, people either have to value the cleanliness enough to do it as well, or you have to tolerate what is the common minimum or find another team/organization.
If the manager is on your side, it's possible but not fun.
Another possible reason could be that they know it’s temporary. A lot of startup code gets rewritten at least once in the first 5 years, there is some art to knowing what code might stick around and be worth the effort to do well, and what you should just bang out fast and move on.
It sounds like it’s possible you haven’t been able to have a conversation with your colleagues about their choices, which might be worth having candidly if you can find the opportunity to do so. If it is ignorance or negligence better to know and decide how you want to proceed if that makes sense.
Once you become competent enough to identify clean code, understand that your perception of clean code is colored by your own experience and current mental context. As you learn, you will undoubtedly be aghast at your own code that you wrote at any time before 6 months ago. After you've been at it for a couple decades you will come to the horrifying conclusion that your mental model is always incomplete, the human brain is weak, and it's hard enough to not get caught in the wrong local maxima without facing up to the immense challenge of choosing between global maxima in the incomprehensible problem space where software meets human needs in the hybrid meat/mental/cyberspace ecosystem where they exist and evolve over time.
The other implication is that no two engineers will ever see things the same way. It's not purely about technical strength—a weaker engineer might come up with a better solution given more time to think about it, or due to some other blind spot or skillset gap from the more senior engineer. Also, there are many issues of style and perspective where the important thing is consistency more so than some specific choice. In those cases there's a high risk of bike-shedding, and it leads to a fundamental truth of large scale software development which is that in practice you will never get everyone on the same page. Of course there are controls for this, but unless you have the budget and operational scope constraints of NASA (or perhaps medical device manufacturers) you can't actually enforce this without losing so much development velocity that your company is utterly uncompetitive in the market.
As you move up the seniority and scale ladder to larger projects and architectures, you will realize that you still only have 24 hours in a day, and it doesn't matter how smart or how right you are, the only tool in your built to increase your impact is a simple cliche: "pick your battles". There is absolutely no upside in nitpicking every line of code that could have a conceivable improvement. If you want respect from your colleagues, you need to get good at filtering what is important and what isn't, and only pointing out the most important issues, and doing it as early in the process as possible.
I appreciate the reminder and the helpful tone of your comment in general!
> As you learn, you will undoubtedly be aghast at your own code that you wrote at any time before 6 months ago.
Just checked, and my code from 6 months ago looks identical to what I write at work. My programming style went through a few different phases but its variability has mostly leveled off since I've started writing in a mostly-functional style.
> It's not purely about technical strength
It's simple stuff like putting together a base Modal display component for re-use instead of copy/pasting that div with the inline-styled zIndex of 99,999 for the umpteenth time.
> As you move up the seniority and scale ladder to larger projects and architectures
I hope to side-step a lot of those pitfalls by exiting the ladder altogether and starting my own company where I take a fine-toothed comb to the process of onboarding new hires. Time will tell if the demands of scaling a company end up sidelining my desire for good hires, but software is still a somewhat nascent field, so the sky's the limit if you ask me!
> the human brain is weak, and it's hard enough to not get caught in the wrong local maxima without facing up to the immense challenge of choosing between global maxima in the incomprehensible problem space where software meets human needs in the hybrid meat/mental/cyberspace ecosystem where they exist and evolve over time.
This is a good way of putting it and it's why it's the problem I've chosen to work on for my first product as a startup founder. I call it Pidgin, and my vision for it is a GUI tool for refactoring and even writing code in a more deterministic and reliable way. I spend my mornings before my day job working on it. I think the fact that I think about code quality intensely at all hours of the day probably contributed to the emotional tone of my initial comment. :)
Is this on the critical path to solving more ambitious goals or just the Sisyphean task you've appointed yourself? It's fine to take pleasure in the small details, and if you want to set up a company to feed that obsession more power to you. However I will go out on a limb and predict two things: 1) unless you are independently wealthy, you are going to stop worrying about this level of detail pretty quickly once you are focused on how to make enough money to afford to hire talented engineers and 2) if you micro-manage style and details to this degree, you may find it hard to retain the level of talent you aspire to.
I took a look at your github profile and looked through your csv_builder repo project in particular. It's good, clean code. Well done! Given that you apparently understand what clean code looks like, I can't help but feel I may be misrepresenting the nature of the 'bad code' I provided an example for. Let me expand on my modal example and perhaps you'll better understand things.
Here's a snippet from the code I had in mind when I wrote my comment:
<div
style={{
display: "flex",
zIndex: 99999,
position: "fixed",
top: 0,
right: 0,
bottom: 0,
left: 0,
}}
>
I won't go deeper into that because that seems like a pretty air tight assumption, but feel free to let me know if it's an invalid assumption on your part nonetheless.
Now, one might say, maybe he didn't know about the other component? And, in fact, I think this was probably the case. And so I can, to some extent, forgive him for copy and pasting due to ignorance of the other component. It's a big codebase and it's impossible to stay up to date on all changes all the time. Nevertheless, this isn't an isolated case, this kind of sloppiness is the rule in the codebase rather than the exception.
> 2) if you micro-manage style and details to this degree, you may find it hard to retain the level of talent you aspire to.
Good engineers make these kinds of mistakes occasionally, it isn't their default mode of programming. I wouldn't have to worry about micro-management because the need for it, at least of the variety concerning this particular example, would never arise. Surely you understand that bad programming can and does exist?
> 1) unless you are independently wealthy, you are going to stop worrying about this level of detail pretty quickly once you are focused on how to make enough money to afford to hire talented engineers
As long as I am responsible for the construction of any kind of software, I will never stop worrying about these kinds of errors because over time they are immensely costly. Team velocity slows drastically due to the unreadable, verbose and repetitive nature of this kind of code. That is unless, of course, the product I'm building manages to embody the vision I have in mind for it and appropriately and sufficiently addresses these kinds of issues such that they are impossible to make anymore. If and when that happens, I will stop worrying because I will rest easy that an automatic process catches these errors and I will be ready to dedicate my brain power to other more interesting problems.
I have no way of knowing exactly how much, but my suspicion is that, in aggregate, sloppy coding such as this likely costs many, many companies building software around the globe millions or even billions of dollars worth of development time every year. I want to alleviate that waste with Pidgin.
And, yeah, devtools aren't exactly the cash cows of software, but they do exist and are occasionally successful. I've got a whole list of SaaS companies in the space, but for brevity I'll simply drop a reference to one I found on HN just this evening. It's called Replay (https://www.replay.io/), and it's a standalone time traveling debugger for web code. They're backed by Andreesen Horowitz, so I think it's likely they have managed to strike on something true.
My aim is for Pidgin to target the process of construction rather than debugging or design as I've seen some other tools do, while still retaining the power of plain text that is invariably lost when using other so-called "low-code" tools.
If you think you might be interested, I would be happy to note your contact details down for when the alpha version is released!
I think this is par for the course in that subfield.
Part of it is the speed at which things change, both in the software ecosystems and in the change requests to sites. The reliance on comprehensive frameworks (which often need tons of workarounds and glue anyway) also reduces people's desire or experience in actually constructing good abstractions.
Compound this with the fact that startup environments generally don't care about anything other than shipping & pivoting, and want to defer all aspects of longevity.
The same problems exist all over the place, but I think are pretty prominent in these situations in particular.
We aren't artists, engineering is exacting field, more details you notice and remember better you can be.
The character trait you should look for how do they present that feedback, is it constructive , is it positive , the kind of language they use and how patient they are able to be.
One interview technique/tool that works for me is asking them to review some sample code mine or a junior devs.
It is easy to gauge how many kinds of issues, how many are actually important and how well they present feedback.
The other technique that worked for me is when I review their code in a interview, people who are agressively bad almost take it poorly and can't take feedback positively .
Interviewing is not 100% representative of on job behaviour, however this helps a lot in filtering out
Well, now everyone is curious for more details on this. Do share :)