3 ms·
Ask HN: Change company culture or quit my job?
I recently join a startup which claims to be a tech startup. The spirit was high during the first week but when I got exposed to the code base, it almost made me cry. There's just no quality in it. The dev team just doesn't have the proper skills and they don't keep good practices like using a version control system, unit tests, code reviews, documentation, so on and on.
There's so much code duplications and gotchas that every time I submit code, it takes days to figure out why my code isn't working (didn't set a flag in the config file, didn't update this in the database, so and so...). The bug fixes are hard coded as if statements and no formula makes sense in this code base.
Now just after a couple of weeks, my morale has dropped badly.
I have two options - to quit or to challenge the culture (and potentially make enemies).
If I quit, jobs are hard to find in country X where I am.
The other option is to challenge the dev team over the code base but they just doesn't understand anything I say (caching, refactoring, unit tests, etc...) and management is still pushing for new features and asking me why I'm not as productive as the other team members - who spend most of the time fixing and introducing bugs.
What should I do?
- fezzl 16y agoWhat's wrong with coding bug fixes as "if" statements?
- hackerblues 16y agoOriginal: def double(x): return x+3 BUG REPORT: double(4) returns 7 instead of 8. Fixed: def double(x): if x == 4: return 8 else: return x+3
- praptak 16y agoI think that's indeed what OP meant, but there's also: def abs(x): return x ... where adding the 'if' seems appropriate :)
- Mz 16y agoI have two options - to quit or to challenge the culture (and potentially make enemies). The English bible says "The meek shall inherit the earth." My understanding is that in French it says "The nonchalant shall inherit the earth." You influence culture every minute of every day by your behavior. Doing so consciously will likely make other people uncomfortable. It can make enemies. But "challenging" it is not the only path. Peace.
- fractallyte 16y agoQuitting is easy. The other way is to plough through the problem. Make management aware of the situation, ask them to create an emergency 'project manager' position, and take the lead. Then you'll have improved the culture, saved your job, and achieved a promotion. Any of your peers who can't handle it - well, that's too bad. Often, although they may not realize it, people WANT to be told what to do. (That may even include your managers...) If that fails - THEN quit ;-)
- petervandijck 16y agoSorry, that's just asking to be fired.
- petervandijck 16y agoChanging company culture is incredibly hard in the best of places. In your case, it sounds impossible. Don't even try, it'll eat your soul. Instead, do the best job your can, while accepting that you can't turn this company around. Be humble: don't tell others they're wrong all the time (even if they are). Be helpful. At the same time, look hard for another job.
- atgm 16y agoQuit. It doesn't sound like you're in a position (new hire, basic programmer) where you have the ability or influence to change the company culture... and with a culture like that, it sounds like the company will be hitting rocky waters at some point -- if you're not happy with their practices now, you certainly don't want to be working your ass off for them when they're in trouble.
- mgkimsal 16y agoPersonally, I'd leave. I've never been good at trying to introduce those sorts of systemic cultural changes. My own experience is that those have either to come from above, or be endorsed and supported by management. Without that support (or directive) efforts will fail, and you'll possibly upset people along the way (although you may upset them anyway). As it is, if you choose to stay, you may ask for a definition of 'productive' that they're using against you. Is it lines of code? Time to get 'feature x' 'live'? Something else? Once you have a definition, quantify the issues you're seeing - the number of bugs that are introduced by 'fast' developers is probably a prime candidate. Ask that bugs be documented - either over a short time period or just outstanding bugs everyone knows of. Get everyone to understand that speed != quality, and that getting stuff done 'fast' is most likely a false economy. If you can get everyone or almost everyone to agree on some of those basics, you can then propose some new processes and measure the effect. None of this will be quick, and it might not be adopted at all. But... I'd suggest documenting this dispassionately, no naming of names or pointing of fingers to specific people. If you are having problems getting up to speed, anyone else probably would as well, so even if they decide to fire you, they won't get anyone else to be as productive. That's probably not actually true - it would depend on how they measure productivity. If it's just a matter of people throwing code out in to production without worrying whether it works or not, then yeah, someone else might be more productive than you. But it is a false economy over the long haul. Also, any new person coming in has a huge learning curve, because there's institutional knowledge gone by not having documentation, unit tests, etc. If they really truly do not see that, it's probably better for your own sanity to find something else. But given the job situation, do what you can to make your case without stepping on anyone's toes.
- arctangent 16y agoIs there a "lead" programmer there? If you don't want to quit then one option would be to convince the founder(s) that you are best placed to ensure the quality and maintainability of the codebase. This is probably worth a pay raise, but do be prepared to bring specific examples of what is going wrong and how your ideas will make the company more profitable.
- throwanay1 16y agoNo, there is no lead programmer and the founder isn't technical. I'm the only person here who actually understands software engineering. I have to write long essays and letters to explain why things aren't the way they should be and I often have to lecture the other developers on what I mean by O(nlogn) vs O(n^2), ftp vs version control, spread sheet vs bug tracking system, project manager vs supervisor, sys admin vs phpmyadmin user.
- arctangent 16y agoIt sounds like quitting may be the best option. But it's always worth seeing if there's a little more money available if you take on extra responsibilities to train up the rest of the team - assuming that this is a trade-off you're happy with.
- sixtofour 16y agoSome choices. a) Be quiet, and try to be as productive as you can. b) Look for a job, then quit. c) Look for a job, and while you're looking, make a first approach to the most receptive management or near management member you can think of. Maybe lunch or beers. Give him a non-emotional, short executive summary of the problem and its consequences. If you get a positive response and you think he understood (pick your manager carefully for this), consider how to cautiously proceed. All three choices are equally valid. c) is obviously complicated and risky, so you have to consider (among many other variables) whether you care enough about this company and your relationship with it to try; whether the entrenched are "know it alls" or are they willing to learn and be better; whether management are managers or slave drivers; whether you can afford a period of unemployment. In other words, is it worth the risk. There are likely other companies that match your goals better than this one.
- throwanay1 16y agoThanks for this. I'll definitely start with b) and c) I really want to help the company but a) is more complicated since it bothers me to know that I just potentially introduced another set of bugs by not addressing the underlying issues.
- petervandijck 16y agoI would recommend combining a) and b).
- ScottBurson 16y agoYou've only been there two weeks and your manager is asking why you're not as productive as the others? Holy crap. Don't just quit, but start looking hard for something else. This place is hopeless; neither the developers nor management have a clue.