Ask HN: Are my expectations on code quality and professionalism too high?
Some time ago, I left a large-ish company with what I perceived as overall quite good engineering to join a smaller company. When I say "quite good", I don't mean perfect, but what I consider the basics were there
- Code review, where we would consider architectural concerns, failure cases, etc. ensuring maintainability. Shortcuts were taken intentionally with a plan to address them
- Test coverage was good enough that you could generally rely on the CI to release to production
- Normal development workflow would be to have tests running while developing, adding tests as you introduce functionality. For some projects that didn't have adequate test coverage, developing might involve running the service locally and connecting to staging instances of dependencies
- Deployments were automated and infrastructure was managed in code
Those are what I consider the basics. Other things I don't expect from every company and am fine setting up myself as needed.
In $current_company, I was surprised that none of the basics were there. All agree to do these things, but with the slightest bit of pressure those principles are gone and people go back to pushing directly to prod, connecting to prod DBs during development, breaking tests, writing spaghetti code with no review, leaving us worse off than we were before. This is frustrating since I see how slow dev is, and I know how fast it is to develop when people write good code with discipline. Most devs in the company don't have experience with other kind of environments (even "senior" ones), I think they just can't imagine another way. My disappointment isn't with the current state, but that people of all levels are making it worse instead of better.
These setbacks are demoralizing, but I'm wondering if my standards are unreasonable. That this is what mid-sized companies are and I just have to endure and keep pushing
305 comments
[ 3.1 ms ] story [ 168 ms ] threadGood practices pay off in overall being able to produce more _correctly working_ code. Even if in the short term it feels like for example writing unit tests "slows you down".
However, if you say you're confident that
> I see how slow dev is
it's just crappy quality and not a trade-off, as I would assume in a usual case.
In my experience it's very easy for company culture, namely in smaller businesses, to get the impression that code quality is a luxury rather than a necessity. And it's even easier to have good intentions, but due to a lack of cultural enforcement just keep them at intentions and never implement anything.
So I would say that you either try to get your standards across or learn to live with lower standards .
You should I believe push for changes with examples of good development practice. Start with easy things that can have impact, and hope the improvement in quality of life due to better practices will stir more interest in improving their process.
But if you have to be the jerk about everything and people just end up resenting you for it, well I think you know what to do.
good luck.
I've been a small business owner, and a software contractor, so I've seen a fair few medium/large python codebase of varying age and quality.
To address your points from the ~10 codebase I've worked on in recent memory:
- Code review: Always in place, though often the CTO has a tendency to merge without review on evenings/weekends
- Test Coverage: Often a challenge - or rather tests are there for coverage, but are of poor quality and don't really assert anything that useful
- Your suggested normal workflow _is_ the normal. Sometimes there's been a dedicated QA team that verifies the changes as seen by the end user too.
- Deployment: Yep. Heroku or k8s have been common, but at least some form of 1-click deploy/promote
Perhaps I've just been super lucky! There are often still major problems in the codebase and refactoring/rebuilding needed to address the challenges, as well as resistance of the existing team to truly change their mindsets to address the problem v.s. the band-aid (or instant gratification) of a quick fix.
Don't give up the fight!
It's a purely mechanical process unlike most of the other problems which depend on changing the behaviour of people in different departments and/or with more influence than you.
Adding the first tests can be a slow and painful process.
Now, once you have those few tests? Yep! Add a few tests along the ones for the new functionality every time you touch a piece of code or pick the low hanging fruit every now and again and you can get to a useful test suite in no time.
Unit testing, for coverage (as a vanity metric) can be mechanical maybe, but integration tests are the way more valuable ones (for the most part) and way more complex.
However, if you think the culture is not conducive to positive, large scale change, it might end up being a waste of your time and energy. Having to constantly say no, and ask for everyone else to fix stuff in PRs can be exhausting. There is also a real risk of others perceiving you as someone who always finds faults with everyone else. That is a hard tag to shake off. Balancing that is the real challenge.
Tests, CI that runs the tests and does not allow release to production if any of the tests is broken, and automated deployment are probably a must.
Code reviews are probably not.
Not sure about infrastructure managed in code.
There are also many companies that go overboard with their code review and tests, get none of the intended gains, produce more slowly than they can, because of an attempt to cater to the lowest denominator. But I suppose if you're going to pick one of two extremes, that would still tend to be the lesser of two evils.
I'm not sure that's necessarily the case. IME, not much will kill both the pace of development and team morale faster than poorly conducted, heavyweight code reviews, but one of the few things that will is a dogmatic requirement to have some unnecessarily high level of code coverage in a test suite where everyone is just writing make-work tests to get the number up.
If you've got a team that is genuinely interested in improving and willing to work on new ideas to make the best use of them, both reviews and testing can obviously be very helpful. That's not really the situation I'm talking about above, though.
I think from the business perspective, they would rather have slow to no changes rather than breaking changes. Presumably there is already a product that makes money, and would continue to do so if kept in a maintenance mode. Layer on poorly applied practices, and you've effectively turned it into that.
If that is their current culture, there will be a lot of pushback if you want to initiate changes. Especially among the senior (responsible for the mess) ones who get defensive real fast.
Maybe ask more about how their engineering culture is next time around during interviews.
I've been trying to improve our standards for years, it never gets traction.
The devs in teams I've worked with (including me) are most of time all quiete aware of the places where their code en setup is lacking and as long as they don't feel personally attacked are very happy with people who come with implementable solutions.
The not feeling attacked and implementable parts are key.
And I've always liked it personally when somebody does that to me. When somebody with a lot more experience and/or skill helps you, it's like some super high level player carrying you through boss fights: you level up much quicker than if you did it on your own.
But I've seen people giving negative responses to the best feedback. Hell, I've had people complaining for hours because someone else replaced their manual process that took an hour to do with a script (and copy&paste of the result) that took literally seconds to run.
I've never personally seen somebody getting fired because a script can do their job. I've seen them being freed from doing the same repetitive bullshit day after day though, and finally being able to actually tackle new challenges.
But unfortunately, that kind of mindset is not something you can change through rational arguments, at least in my experience.
But I agree with the last sentence. This is a huge mistake, and it seems that the author did not ask these proper questions during his interviews. Perhaps, this is the most valuable lesson to him from the story. You have to know which company you are going to join and the state of engineering.
If it's the former and you've come into the small company with more experience than most people there, you might get a long way and become quite popular with your colleagues if you share the benefit of that experience intelligently. For example, with the agreement of the senior people, you could show everyone how to set up a good CI system or automated deployments, if that's something you know how to do and they don't. These kinds of things tend to have obvious benefits once they're up and running, but setting them up in the first place can be a barrier depending on what else you're using, how everything you've already got fits together, and of course the level of knowledge and awareness of the people working on it.
On the other hand, if everyone is well aware that they should be doing something and they know how to but just can't be bothered, that's a cultural problem that you're unlikely to be able to change as the newbie. Probably no-one else is either, unless they're doing it from the top down and have hiring and firing privileges to force the issue by bringing in more people who expect it and, if necessary, letting go anyone who stubbornly refuses to engage. If this is the environment you're in, unfortunately putting up with it or getting out are probably your only certain options.
If it's a skills problem, by all means set everything up and be the hero.
If it's a cultural problem, run.
Just be thankful the devs can “push” to production and aren’t individually rsyncing their code into the app servers. :)
So like for automated tests if the leadership currently thinks that test code isn't actually doing anything for the customer so why should it be done? Then you have to show how much money/time/whatever has been spent by engineering fixing the same bug over and over because you lack regression tests and compare that to how much would have been spent to write a test case for that regression.
But I'm getting too much resistance from "senior" developers who've been there for 15-16 years. Everyone agreed to do X and circumvented it the very next day.
This consumed so much of my time(outside office hours) and energy that now I feel why do I bother making a change when I'm not getting paid or even recognized for it.
So like any project it works best if you do one thing at a time and build up some momentum. You can't fix everything at once.
See if you can get people to buy in to just getting the indentation consistent (my favorite place to start), or preventing the development software from touching the production database.
Get one win, give it a little time, and then go for another pass. Meanwhile set an example in your own contributions. It is very possible to improve things but it takes patience, planning how to deal with setbacks, flexibility, and recognizing what the real priorities of the company are and what quality means in context.
There are very limited conditions, under which making this a blame exercise would be the right answer.
There are also business conditions, under which this situation is the best that the business could have achieved by now. Eg, if other things needed to be higher priority for the viability of the business. Having said that, once you are in such a situation it is difficult to get out of it, and hence such situations tend to linger for much longer than any justification.
What you probably need to do now is find out how much appetite there is to change, and what the blockers are.
"what the human and business factors that led to where the company is now, and how to approach changing it"
This is a people problem, not a technology problem (or an opportunity if you look at things that way).
Continuous integration was only proposed as a concept 30 years ago, and was a relatively fringe theory for another decade at least. Automated deployment followed a similar path, but about a decade later. Manual acceptance tests, in particular, remained quite common a decade ago even at the big tech giants.
The hint is "spaghetti code".
What might have happened is you started slagging off everyone's code as soon as you've come in and now you're plucking at straws to justify it as you're getting ostracized.
Also, objectively speaking, how can writing MORE code and spending MORE time talking to people be faster? Your argument makes no sense. Tests and reviews are a massive drag on development, also more code means more bugs. That we know.
It would take years to get full test coverage and somehow you think that makes everyone inherently faster?
Also, ask yourself this, how much money have they lost so far by doing this? Is it perchance $0? Zero downtime? As you've not listed a single actual COST of what they're doing.
While direct to prod/connect to prod db is nuts and not normal, you also haven't given the context of who did that and why they did that. Is there really no staging server? No Dev branch?
What's special about that?
How can writing MORE code be faster? Be honest with yourself, you know it's slower, it's hard to get right, and it's easy for many programmers to end up writing really bad tests that hinder rather than help.
Certain orgs might be able to pull it off, but generally speaking it's cargo culting.
Then you can confidently and automatically deploy to prod straight away without much manual checking.
making sure no more of it gets to production has become a top priority company-wide
I think it's hard for people to appreciate thw other side of these argumenta without having lives through some consequences. I firmly believe in automation and testing. I believe tests must be pragmatic to not be overbearing. I mostly believe in code review for teaching. The research covered in the book Accelerate (subtitle something something devops) made a strong case against code review and change control for most software development.
So yeah, your standards sound reasonable, if maybe a bit much for my taste in some aspects but I know lots of shops that wouldn't be anywhere near. And this is a skillset and know-how you can provide. Hope that's a useful perspective.
Your expectations are perfectly reasonable. I think you should consider explaining to everyone (including non-developers) how bad things can go if these practices continue.
That's all I have to say about this: If the company tanks and you forget about good practices, you're toast.