Ask HN: How you ever quit because the engineering culture is too messed up?
23 comments
This can be frustrating for sure. Your question / post is a little light on details, so I am reading between the lines a bit here, but to some extent you'll find this everywhere, and dealing with it can be a useful skill.
Can you provide a few more details on what you mean by "management infrastructure"? Are we talking source control / build systems / JIRA workflow stuff here?
I would suggest trying to find ways to be productive yourself that don't involve changing what other people do.
Don't try to sell "ideas" and "proposals", lead by example, and if it works out people will follow.
For example, if people want to use subversion and do their development on trunk, but you want to use git with feature branches... then just do that for your local development, create and switch branches locally all you want, and then push to subversion when you're done.
If there's some dumb JIRA workflow, copy and paste the details to a text file, work on the thing, take your notes in the text file, paste it back to JIRA when you're done. You will probably find you can isolate yourself from most kinds of silliness quite well, and if you're productive doing so then others will follow.
As for your specific question, I think it's worth trying to improve things for at least a year, or maybe two, before you consider leaving. In that time, you'll probably find there are things you can change, learn that other things are actually not as easy to change as you might think, and generally build some useful experience in turning around a challenging situation.
Can you provide a few more details on what you mean by "management infrastructure"? Are we talking source control / build systems / JIRA workflow stuff here?
I would suggest trying to find ways to be productive yourself that don't involve changing what other people do.
Don't try to sell "ideas" and "proposals", lead by example, and if it works out people will follow.
For example, if people want to use subversion and do their development on trunk, but you want to use git with feature branches... then just do that for your local development, create and switch branches locally all you want, and then push to subversion when you're done.
If there's some dumb JIRA workflow, copy and paste the details to a text file, work on the thing, take your notes in the text file, paste it back to JIRA when you're done. You will probably find you can isolate yourself from most kinds of silliness quite well, and if you're productive doing so then others will follow.
As for your specific question, I think it's worth trying to improve things for at least a year, or maybe two, before you consider leaving. In that time, you'll probably find there are things you can change, learn that other things are actually not as easy to change as you might think, and generally build some useful experience in turning around a challenging situation.
+1 to the approach of leading by example. I sometimes phrase it as, "Focus on what you can change, rather than what you cannot."
It is difficult to be in that environment that doesn't have a good engineering culture. It, however, should not stop you from doing what you believe is right.
If you are relatively new to the company, in order to bring influence, it might be worth it to build trust before "rocking the boat." Trust could be built through leading by example, or sometimes just take the time and understand why the process exists in the first place. Once people trust you, it may be easier to sell/propose new ideas to the team.
As an anecdote, I've worked in a startup in the past that allows engineers to push and deploy code to production without any form of code review or a single line of tests written. (Even senior engineers/tech leads do not always have tests to go with their commits.) This created a code base that contains quite a bit of spaghetti code, occasional build breakage, as well as a lack of knowledge sharing on different components (Even if you are on the same team working in a similar area of the code base.)
Rather than changing the process to mandate PR, I started creating a Pull Request (PR) for every single change that I made, made sure I have sufficient test coverage and added my teammates to it. If my teammate happened to leave a comment/feedback, I'll thank them on Slack, and let them know the feedback is useful.
Since then, while there are still changes that went out without any reviews, I've seen more reviews coming my way (2-3 in 3 months versus 3-5 in a week), and I always do my best to leave feedback/comment on the PRs asap. It wasn't perfect, but hopefully, these baby steps laid the foundation to lead to an eventual change.
John Wooden (Ex-UCLA coach) has a well-known quote, "Make each day your masterpiece." Rather than focusing on what I cannot change (Other people + process), I did what I can to make it better (My "masterpiece" given the circumstances), and I hope what I did may have changed how my teammates looked at PR.
It is difficult to be in that environment that doesn't have a good engineering culture. It, however, should not stop you from doing what you believe is right.
If you are relatively new to the company, in order to bring influence, it might be worth it to build trust before "rocking the boat." Trust could be built through leading by example, or sometimes just take the time and understand why the process exists in the first place. Once people trust you, it may be easier to sell/propose new ideas to the team.
As an anecdote, I've worked in a startup in the past that allows engineers to push and deploy code to production without any form of code review or a single line of tests written. (Even senior engineers/tech leads do not always have tests to go with their commits.) This created a code base that contains quite a bit of spaghetti code, occasional build breakage, as well as a lack of knowledge sharing on different components (Even if you are on the same team working in a similar area of the code base.)
Rather than changing the process to mandate PR, I started creating a Pull Request (PR) for every single change that I made, made sure I have sufficient test coverage and added my teammates to it. If my teammate happened to leave a comment/feedback, I'll thank them on Slack, and let them know the feedback is useful.
Since then, while there are still changes that went out without any reviews, I've seen more reviews coming my way (2-3 in 3 months versus 3-5 in a week), and I always do my best to leave feedback/comment on the PRs asap. It wasn't perfect, but hopefully, these baby steps laid the foundation to lead to an eventual change.
John Wooden (Ex-UCLA coach) has a well-known quote, "Make each day your masterpiece." Rather than focusing on what I cannot change (Other people + process), I did what I can to make it better (My "masterpiece" given the circumstances), and I hope what I did may have changed how my teammates looked at PR.
I love John Wooden. He's eloquent and full of fantastic life lessons. I always jokingly say he's my spirit animal for a reason.
There's a certain disdain for metrics so we're not tracking a lot of things proactively (think latency/rate, for example). That means every new change is based on a feeling of how it'll impact the systems. We also don't have a dev/test environment so changes to production are what I'd call, "faith based". There's a lot of apply to production, revert cycles. Or worse: no changes at all for fear of breaking things.
But there are more mundane things like not using a code linter because $linter enforces some rule that someone doesn't like, so discussions stall. There are literally hundreds of JIRA tickets about some proposed idea that fails to reach consensus.
I think isolating myself from the craziness is a good idea but I'm having trouble with how it would be received. Say I push a code change that fixes a bunch of things that $linter complained about, including stylistic changes. Now that has to be reviewed by someone and...? Should I just keep pushing the envelope like that? Someone will probably contribute some piece of code full of violations and then... I fix it and cause an incident with teammates?
One possible outcome is to just accept things and let go. I see this a lot in people that have been here for many years. They are also not people I would aspire to be so... I kind of have to accept defeat but that's demoralizing. I'm coming to a point where I'm asking myself where I could be and I don't have a good answer. Should I stick around and keep trying to change things? Back to the swimming against the current question.
Thanks for all the feedback.
But there are more mundane things like not using a code linter because $linter enforces some rule that someone doesn't like, so discussions stall. There are literally hundreds of JIRA tickets about some proposed idea that fails to reach consensus.
I think isolating myself from the craziness is a good idea but I'm having trouble with how it would be received. Say I push a code change that fixes a bunch of things that $linter complained about, including stylistic changes. Now that has to be reviewed by someone and...? Should I just keep pushing the envelope like that? Someone will probably contribute some piece of code full of violations and then... I fix it and cause an incident with teammates?
One possible outcome is to just accept things and let go. I see this a lot in people that have been here for many years. They are also not people I would aspire to be so... I kind of have to accept defeat but that's demoralizing. I'm coming to a point where I'm asking myself where I could be and I don't have a good answer. Should I stick around and keep trying to change things? Back to the swimming against the current question.
Thanks for all the feedback.
If you think it's valuable to track latency, that seems like something you could just do. Grab the logfiles process them in your home directory, produce some graphs, keep the data over time and track changes. Ideally it would be done centrally, but as a starting point just do it yourself.
Not having a dev / test / qa environment is inexcusable, why do you not have that? Why can't you just set one up yourself? Possibly on your own workstation or some VMs, just find a way to do it.
Linter warnings are of highly variable quality. Don't bother about anything stylistic - tabs vs spaces, camel case vs underscores - those things never caused anyone's software to not work. Ask yourself "could this break something in production?".
If the answer is yes, then create a code change to fix one instance of the problem and submit it for review (not every instance of every problem, just one instance of one specific problem that could affect production). People will ask why it's a problem, you can explain it, and if you've selected a good example of a non-trivial problem, they'll accept it and merge it. Then, go and find the other instances of the same problem after you have set the precedent, and there will be less resistance. Then, start working on other problems, rinse and repeat.
Doing this will educate people along the way, and will work better than some big shock-and-awe change that touches a lot of things at once. Go easy on criticizing other people's work during code review, they're often emotionally attached to their code at that point since it's the last step in something they've been working on for weeks and want to move on from. Again, only raise things in other peoples code that could break things in production.
As for accepting things and letting go, I'd say it's more a question of picking your battles. Don't accept everything and let go. Try to improve things to the extent you can while you are there, even if that isn't forever.
Not having a dev / test / qa environment is inexcusable, why do you not have that? Why can't you just set one up yourself? Possibly on your own workstation or some VMs, just find a way to do it.
Linter warnings are of highly variable quality. Don't bother about anything stylistic - tabs vs spaces, camel case vs underscores - those things never caused anyone's software to not work. Ask yourself "could this break something in production?".
If the answer is yes, then create a code change to fix one instance of the problem and submit it for review (not every instance of every problem, just one instance of one specific problem that could affect production). People will ask why it's a problem, you can explain it, and if you've selected a good example of a non-trivial problem, they'll accept it and merge it. Then, go and find the other instances of the same problem after you have set the precedent, and there will be less resistance. Then, start working on other problems, rinse and repeat.
Doing this will educate people along the way, and will work better than some big shock-and-awe change that touches a lot of things at once. Go easy on criticizing other people's work during code review, they're often emotionally attached to their code at that point since it's the last step in something they've been working on for weeks and want to move on from. Again, only raise things in other peoples code that could break things in production.
As for accepting things and letting go, I'd say it's more a question of picking your battles. Don't accept everything and let go. Try to improve things to the extent you can while you are there, even if that isn't forever.
Honestly it’s disingenuous for people to suggest that one person (in this case, you) can somehow fix everything by “leading by example”. That’s first and foremost a management job. So first you need to decide whether you have management support for the changes you’d like to see.
Start by examining the behaviors and outcomes your managers currently reward. This will tell you their true priorities.
Next, determine if management is rewarding those behaviors because that’s the best way they know (ignorance) or other reasons, e.g. politics, don’t care, empire building, etc. Ignorance is potentially fixable, anything else is a sign you won’t be successful.
If you’ve found that management is simply ignorant, see if they’re open to learning new things. If not, you’ll find yourself preaching to the deaf. Find another job.
Also be aware that survivor bias means that your coworkers are well adapted to the status quo. They will likely resist changes as well. See if you have any allies amongst the troops. If not, leave.
I know that this advice is heavily biased against staying, but with good reason: Cultural change is extremely difficult, and even CEOs, who theoretically have the most power to make changes, often fail at it. Better to find a culture that’s ready for the change you want to help with, rather than to stay in one that doesn’t.
Good luck!
Start by examining the behaviors and outcomes your managers currently reward. This will tell you their true priorities.
Next, determine if management is rewarding those behaviors because that’s the best way they know (ignorance) or other reasons, e.g. politics, don’t care, empire building, etc. Ignorance is potentially fixable, anything else is a sign you won’t be successful.
If you’ve found that management is simply ignorant, see if they’re open to learning new things. If not, you’ll find yourself preaching to the deaf. Find another job.
Also be aware that survivor bias means that your coworkers are well adapted to the status quo. They will likely resist changes as well. See if you have any allies amongst the troops. If not, leave.
I know that this advice is heavily biased against staying, but with good reason: Cultural change is extremely difficult, and even CEOs, who theoretically have the most power to make changes, often fail at it. Better to find a culture that’s ready for the change you want to help with, rather than to stay in one that doesn’t.
Good luck!
Life's too short to work for bad companies. Cultures rarely change though, so if you can't change some of their habits it never will. And generally bad cultures will scare away top talent.
But generally, first thing is to check whether your ideas would actually help.
Some ideas sound great and are supported by great people, but they kill flow, e.g. scheduling, stand ups, TDD, and other project management practices.
Some ideas have a lot of overhead, and every project has a balance between how much should be hacked, vs time saved in the long term.
And sometimes it's just that it's challenging someone's authority. Or because they feel they are already the best and doing things the best way. If this is the case, then you could consider leaving.
But generally, first thing is to check whether your ideas would actually help.
Some ideas sound great and are supported by great people, but they kill flow, e.g. scheduling, stand ups, TDD, and other project management practices.
Some ideas have a lot of overhead, and every project has a balance between how much should be hacked, vs time saved in the long term.
And sometimes it's just that it's challenging someone's authority. Or because they feel they are already the best and doing things the best way. If this is the case, then you could consider leaving.
Yes, I have done this. Mostly because my work depended on certain technical architecture being setup but there was an unwillingness by management to do so. This was primarily because other people at the company refused to admit they didn’t have the expertise to set it up and instead did their best to cause my project to drag for months. I eventually left and completed a project that dragged for over 2 years in less than 3 months for another company.
It was overall a very frustrating and stressful part of my life that I would have done everything in my power to not be involved in if I could have predicted the future.
It was overall a very frustrating and stressful part of my life that I would have done everything in my power to not be involved in if I could have predicted the future.
That's exactly one of the problems that I have. Somehow people are okay with things taking 2 years rather than 3 months though so there isn't a lot of pressure to change.
I'm at a point where I don't know if sticking around can have a positive influence on my career, maybe I'll learn to be more zen? How will that help if I change jobs? Or, will I become used to bad engineering and sabotage myself in the future? These are the kind of questions I'm having.
Assuming I have a good set of skills and enough experience, when faced with a challenging situation like this, I should try to be a positive force and bring improvements. However, I'm failing at that constantly and I just think it could have a negative impact on myself (burnout is a fact at this point).
Really trying to find the silver lining in all of this.
I'm at a point where I don't know if sticking around can have a positive influence on my career, maybe I'll learn to be more zen? How will that help if I change jobs? Or, will I become used to bad engineering and sabotage myself in the future? These are the kind of questions I'm having.
Assuming I have a good set of skills and enough experience, when faced with a challenging situation like this, I should try to be a positive force and bring improvements. However, I'm failing at that constantly and I just think it could have a negative impact on myself (burnout is a fact at this point).
Really trying to find the silver lining in all of this.
I think being zen is important for dealing with interpersonal situations however I think it is a mistake to be too accepting of the status quo when it comes to getting things done. Your time is valuable.
What has worked for me in the past is to find people that are able to force changes to the product (typically project or product managers, or someone else that represents the client) and find out what they need, then focus on producing something for them that gets them further down the path they are taking the product or company. These can be small things or big things, if you can help them create progress then you have a valuable advocate moving forward.
If there is no way to do that within the current engineering processes at your company then consider working outside those processes, and if that is not possible then you should look for opportunities at other organizations.
What has worked for me in the past is to find people that are able to force changes to the product (typically project or product managers, or someone else that represents the client) and find out what they need, then focus on producing something for them that gets them further down the path they are taking the product or company. These can be small things or big things, if you can help them create progress then you have a valuable advocate moving forward.
If there is no way to do that within the current engineering processes at your company then consider working outside those processes, and if that is not possible then you should look for opportunities at other organizations.
Culture comes from the top. That culture is busted. The fact you can spot problems and solutions plus you care enough to try is a big indicator you're far better off in a culture that will utilize your mindset much better.
Forcing changes in already messed culture may backfire. You need to take the confidence of key peoples in the team before 'forcing'.
(I answered this in the other thread, but thought I'd crosspost here too)
It can be a tricky one, but fundamentally the _reason_ why change isn't happening needs to be understood. A company full of smart people is unlikely to _never_ want change for any reason - especially if that change would clearly make everyone's life easier. But maybe everyone is overloaded with work and a bit burnt out, so 'big' change is scary to them? Or perhaps the 'important change' really isn't that important? I've worked with devs before who have spoken for hours a day on the need to change x, y and z, when in reality it wasn't fully needed (and/or their suggestions stemmed from misunderstandings).
I guess my latter point there relates to the fact that there's not always a single "right way" of doing something.
Now I know that this might sound like I'm the same as the people shooting down your suggestions in your linked 'Ask HN' thread. Trust me, I'm not like that: I left my previous job a few months ago for the exact same reasons that you have outlined (i.e. there was clear change that was needed, but the 'powers that be' weren't willing to make those changes).
But to circle back to your question: assuming there aren't massive organizational problems at a company, change usually needs to be made slowly-but-surely with the buy-in of any previous 'change blockers' (where possible). Anyone trying to force through lots of change in a short period of time will usually struggle.
If even minor change is not possible, there's two main possibilities:
1) You're wrong about the change, and you might be the problem.
2) You're right about the change, the company is dysfunctional, and moving to a new job is the answer.
From your linked thread, (2) does sound like the situation in your case (fortunately/unfortunately).
It can be a tricky one, but fundamentally the _reason_ why change isn't happening needs to be understood. A company full of smart people is unlikely to _never_ want change for any reason - especially if that change would clearly make everyone's life easier. But maybe everyone is overloaded with work and a bit burnt out, so 'big' change is scary to them? Or perhaps the 'important change' really isn't that important? I've worked with devs before who have spoken for hours a day on the need to change x, y and z, when in reality it wasn't fully needed (and/or their suggestions stemmed from misunderstandings).
I guess my latter point there relates to the fact that there's not always a single "right way" of doing something.
Now I know that this might sound like I'm the same as the people shooting down your suggestions in your linked 'Ask HN' thread. Trust me, I'm not like that: I left my previous job a few months ago for the exact same reasons that you have outlined (i.e. there was clear change that was needed, but the 'powers that be' weren't willing to make those changes).
But to circle back to your question: assuming there aren't massive organizational problems at a company, change usually needs to be made slowly-but-surely with the buy-in of any previous 'change blockers' (where possible). Anyone trying to force through lots of change in a short period of time will usually struggle.
If even minor change is not possible, there's two main possibilities:
1) You're wrong about the change, and you might be the problem.
2) You're right about the change, the company is dysfunctional, and moving to a new job is the answer.
From your linked thread, (2) does sound like the situation in your case (fortunately/unfortunately).
Throwaway for obvious reasons...
I worked at a YC startup a couple of years ago. The day after I started, the guy who hired me (eng manager) quit. All engineers reported to the CEO (former dev). That was the first red flag.
The second red flag occurred a week or two later, when two of the other three engineers cornered me in a room and tried to convince me that I should do what they say instead of what the CEO wanted. Second red flag.
Third red flag was when any tough decisions were made, the CEO would leave it up to us to work out amongst ourselves. Majority ruled. He was so afraid of pissing off any of his engineers that he just wouldn't do anything at all. Total clusterfuck.
They would play games once a week to try and team build, but it was a joke. Nobody trusted anybody else, and everyone was trying to undermine the CEO. Technically, they were doing things fairly OK. They wanted 100% unit test coverage, they had a proper CI/CD pipeline, they expected 2 people to approve every PR, they versioned their APIs appropriately. But none of that works if the people culture blows. And this one blew hard.
I stuck around as long as I could while I tried to find something else, but I couldn't have been more glad to leave a place. It was hell working there.
I worked at a YC startup a couple of years ago. The day after I started, the guy who hired me (eng manager) quit. All engineers reported to the CEO (former dev). That was the first red flag.
The second red flag occurred a week or two later, when two of the other three engineers cornered me in a room and tried to convince me that I should do what they say instead of what the CEO wanted. Second red flag.
Third red flag was when any tough decisions were made, the CEO would leave it up to us to work out amongst ourselves. Majority ruled. He was so afraid of pissing off any of his engineers that he just wouldn't do anything at all. Total clusterfuck.
They would play games once a week to try and team build, but it was a joke. Nobody trusted anybody else, and everyone was trying to undermine the CEO. Technically, they were doing things fairly OK. They wanted 100% unit test coverage, they had a proper CI/CD pipeline, they expected 2 people to approve every PR, they versioned their APIs appropriately. But none of that works if the people culture blows. And this one blew hard.
I stuck around as long as I could while I tried to find something else, but I couldn't have been more glad to leave a place. It was hell working there.
I quit one job in 1995 when they decided to abandon SunOS/Solaris work in favor of Windows NT. Someone at Microsoft had sold this company on the idea that if their developers used Windows NT (3.5? 3.11? can't remember) they'd be 5 times more productive. This was obviously untrue, and I didn't want to get caught between the hammer of management and the anvil of Windows NT.
I once worked at a place where everyone working there was recruited straight out of school. They were nurturing a mentality of "I don't have to learn things ever again". Mind you, they were using Delphi 2010 at the time but were stuck in their old ways, using DataSets like it was 1998.
I was hired and had about 3 years of experience back then. It seemed like they tought they knew everything about software development at that point and swore to themselves to would never learn something new again. They were perfectly happy with their "misc" file, containing somewhere near 45K lines of code, hundreds of functions that were totally unrelated. Nothing wrong with that, according to them.
So yeah, I spent 8 months there. One wednesday afternoon, I had enough and went to my boss, handed my resignation, and never stepped in that office ever again.
I was hired and had about 3 years of experience back then. It seemed like they tought they knew everything about software development at that point and swore to themselves to would never learn something new again. They were perfectly happy with their "misc" file, containing somewhere near 45K lines of code, hundreds of functions that were totally unrelated. Nothing wrong with that, according to them.
So yeah, I spent 8 months there. One wednesday afternoon, I had enough and went to my boss, handed my resignation, and never stepped in that office ever again.
How long have you been there?
If you're brand new, then just be quiet and listen for 6 months. Find out why they do things the way they do. They often have, if not totally valid reasons, at least reasons that are more valid than they seem at first glance. If you don't know their reasons, and you're telling them that they should do it differently, then of course the aren't listening to you.
But if you've been there for a while, you know which are the bad ideas, and you can't get them to listen to better ones, and that frustrates you, then it may well be time to leave.
If you're brand new, then just be quiet and listen for 6 months. Find out why they do things the way they do. They often have, if not totally valid reasons, at least reasons that are more valid than they seem at first glance. If you don't know their reasons, and you're telling them that they should do it differently, then of course the aren't listening to you.
But if you've been there for a while, you know which are the bad ideas, and you can't get them to listen to better ones, and that frustrates you, then it may well be time to leave.
Worst advice ever. The time will pass regardless of your waiting, so everything you could see in 6 months you'll see. But while the time passes you can do something. As you stay quiet and watch you accumulate negative momentum and estabilish the narrative of a passive teammate. It is difficult to start anew in the environment you've been in for a while. Difficult to challenge solidifed perceptions.
Wreak havoc from the very beginning but with tact. Never insulting anybody, always carrying positive energy. This way you'll get the reputation of a go getter, an executioner, and will become the proactive force.
> If you don't know their reasons, and you're telling them that they should do it differently, then of course the aren't listening to you.
Do not accept this. Just because they have valid reasons doesn't mean your way is wrong, worse, and not worth it. They have valid excuses for everything, that's the way of the world. In any case there is always something to improve from day 0.
That's my way of thinking. My experience is limited though.
Wreak havoc from the very beginning but with tact. Never insulting anybody, always carrying positive energy. This way you'll get the reputation of a go getter, an executioner, and will become the proactive force.
> If you don't know their reasons, and you're telling them that they should do it differently, then of course the aren't listening to you.
Do not accept this. Just because they have valid reasons doesn't mean your way is wrong, worse, and not worth it. They have valid excuses for everything, that's the way of the world. In any case there is always something to improve from day 0.
That's my way of thinking. My experience is limited though.
[deleted]
Apologies for the wrong thread title. I meant "Have you ever". Sometimes I read stuff over and over and over and still reads fine but is wrong. Oh well, sorry.
I did, multiple times. I have lots of savings so my tolerance for frustration is lower than people who are living paycheck to paycheck.
Yes, I have done this. I joined a small start-up as a developer, and they admitted they needed to increase their professionalism and they would stand behind me as I did so. This was around 2005 or so when standards weren't as good as they are now.
Management consisted of designers and a self-taught programmer. While extremely intelligent, his ego could get in the way of making a good design decision - he didn't take kindly to constructive criticism or alternative ideas and would sometimes invent articles he had supposedly read that supported his biases. This was effectively the number one problem and in retrospect after identifying this, I should have left much sooner.
They failed every single question in the Joel Test and by the end the only points I had managed to change were to introduce source control and to introduce a bug database.
I look back on those days and I did enjoy the working environment to an extent and I enjoyed working with the people and even the technical co-founder was a really good guy out of work (and as I said, next-level intelligent) but the engineering culture was preventing me from doing my best work so I quit.
The final straw was when I was being shouted at in front of a client for introducing a bug in production that I could have sworn I had fixed weeks ago. After investigating it I discovered the co-founder had made a change, encountered a failing unit test and just deleted the test instead of fixing the underlying problem. The commit message was just "z" and came along with a few dozen unrelated changes.
The company is still around and I understand doing well. Every now and again though I encounter their product and I'm able to replicate a bug I first added to the bug tracker in around 2006. I feel they are doing well because they had a genuinely good idea and brought it to market sooner than anyone.
I won't say who they are because I don't wish to publicly shame them. I hope they have a better engineering culture now.
The next company I worked for had all the same problems except for the co-founder with an ego problem and I was able to get them to an extremely high level of professionalism and left behind an extremely high functioning software team after I moved on to the next level in my career.
To conclude: If your company has a poor engineering culture and it is getting in the way of you doing your best work then you should resign and find another job. You can still see the people you like at that company socially if you want but staying there won't help your career.
Management consisted of designers and a self-taught programmer. While extremely intelligent, his ego could get in the way of making a good design decision - he didn't take kindly to constructive criticism or alternative ideas and would sometimes invent articles he had supposedly read that supported his biases. This was effectively the number one problem and in retrospect after identifying this, I should have left much sooner.
They failed every single question in the Joel Test and by the end the only points I had managed to change were to introduce source control and to introduce a bug database.
I look back on those days and I did enjoy the working environment to an extent and I enjoyed working with the people and even the technical co-founder was a really good guy out of work (and as I said, next-level intelligent) but the engineering culture was preventing me from doing my best work so I quit.
The final straw was when I was being shouted at in front of a client for introducing a bug in production that I could have sworn I had fixed weeks ago. After investigating it I discovered the co-founder had made a change, encountered a failing unit test and just deleted the test instead of fixing the underlying problem. The commit message was just "z" and came along with a few dozen unrelated changes.
The company is still around and I understand doing well. Every now and again though I encounter their product and I'm able to replicate a bug I first added to the bug tracker in around 2006. I feel they are doing well because they had a genuinely good idea and brought it to market sooner than anyone.
I won't say who they are because I don't wish to publicly shame them. I hope they have a better engineering culture now.
The next company I worked for had all the same problems except for the co-founder with an ego problem and I was able to get them to an extremely high level of professionalism and left behind an extremely high functioning software team after I moved on to the next level in my career.
To conclude: If your company has a poor engineering culture and it is getting in the way of you doing your best work then you should resign and find another job. You can still see the people you like at that company socially if you want but staying there won't help your career.
I haven't, but I was working as the lead developer for an agency on a big-name client in the financial industry.
My point of contact was their head of marketing, who said that all development had to go through the IT team. Despite having a large web presence, their VP of IT was adament that IT would handle all web-related work. Their developers were all employed and trained as IT technicians, even though they came from development backgrounds. Obviously, finance is a protected industry, so working IT in a place like that is no joke, but having IT handle all software development AND the maintnenace of IT systems meant that nothing got done, and when outside work was brought in they had to confirm to crazy standards.
Anyway, I was brought in to fix some build systems, built by a previous company. I spent three days there and got it working in the end. I actually spent most of my time chatting to the marketing lady, who was constantly asking me hypotheticals about how things work with other clients, how long it takes to get changes made/approved on a website, etc. Her questions were quite in-depth around clients we already had, and I said roughly how things worked. A week later, the VP of IT kicked off about unapproved work on the website build server (which was approved by one of the IT/dev guys), and she resigned. A week after that, she was a marketing director at the client she had questioned about.
I ended up chatting to her face-to-face a few weeks later, and she said there was a huge split in the company on how the engineering team should be run, causing nearly a dozen developers to join her at this new company. They all handed in their notice within the week, and the VP was so pissed off he put them all on paid gardening leave and told them to never come back.
Fast forward around a year, and I was at a conference taking a workshop on BDD with a new employer. A few of us were chatting to the guy running the workshop, when one guy chimes in about why he was on the course. He said some idiots at [Company Name] had built an awful website with a crazy build server setup, and that their IT team were looking to learn enough to perform a complete rebuild. The company name was my old employer, but the cringe doesn't end there. The person running the workshop was employed at the company that initially built the website and the build server, and I remembered his name in the commit logs as the one that lead the entire build. Their IT guys were literally bitching about incompetent developers to the guy that had built their systems, and his face dropped when he figured out they were bitching about his project. Despite trying to skirt around the subject or justify why some things are built the way they are, we sat there for twenty minutes as they tore apart what I'd consider a valid setup (onsite TeamCity, generated build scripts and artifacts running on a separate secure box to ensure that the site could be deployed if the build server went down, and a test suite to switch a blue/green type setup).
I pryed about their team, and they said that their IT team was trimmed to run a lean senior-level team. In the space of 18 months they had lost at least 20-25 people, and their IT/engineering team were going to rebuild a large-scale website with very little web development expeirence, all while maintaining the IT systems for a fairly large company. To pry further, I pretended to know a developer that had worked there previously, and the guy smugly said "well, if he's not there any more he was cut - not everyone can handle what we do".
It's been a few years since then, and from what I can tell they're still running the same website. I wish I could remember this guys name or the VP's name, just to see if they are still there.
My point of contact was their head of marketing, who said that all development had to go through the IT team. Despite having a large web presence, their VP of IT was adament that IT would handle all web-related work. Their developers were all employed and trained as IT technicians, even though they came from development backgrounds. Obviously, finance is a protected industry, so working IT in a place like that is no joke, but having IT handle all software development AND the maintnenace of IT systems meant that nothing got done, and when outside work was brought in they had to confirm to crazy standards.
Anyway, I was brought in to fix some build systems, built by a previous company. I spent three days there and got it working in the end. I actually spent most of my time chatting to the marketing lady, who was constantly asking me hypotheticals about how things work with other clients, how long it takes to get changes made/approved on a website, etc. Her questions were quite in-depth around clients we already had, and I said roughly how things worked. A week later, the VP of IT kicked off about unapproved work on the website build server (which was approved by one of the IT/dev guys), and she resigned. A week after that, she was a marketing director at the client she had questioned about.
I ended up chatting to her face-to-face a few weeks later, and she said there was a huge split in the company on how the engineering team should be run, causing nearly a dozen developers to join her at this new company. They all handed in their notice within the week, and the VP was so pissed off he put them all on paid gardening leave and told them to never come back.
Fast forward around a year, and I was at a conference taking a workshop on BDD with a new employer. A few of us were chatting to the guy running the workshop, when one guy chimes in about why he was on the course. He said some idiots at [Company Name] had built an awful website with a crazy build server setup, and that their IT team were looking to learn enough to perform a complete rebuild. The company name was my old employer, but the cringe doesn't end there. The person running the workshop was employed at the company that initially built the website and the build server, and I remembered his name in the commit logs as the one that lead the entire build. Their IT guys were literally bitching about incompetent developers to the guy that had built their systems, and his face dropped when he figured out they were bitching about his project. Despite trying to skirt around the subject or justify why some things are built the way they are, we sat there for twenty minutes as they tore apart what I'd consider a valid setup (onsite TeamCity, generated build scripts and artifacts running on a separate secure box to ensure that the site could be deployed if the build server went down, and a test suite to switch a blue/green type setup).
I pryed about their team, and they said that their IT team was trimmed to run a lean senior-level team. In the space of 18 months they had lost at least 20-25 people, and their IT/engineering team were going to rebuild a large-scale website with very little web development expeirence, all while maintaining the IT systems for a fairly large company. To pry further, I pretended to know a developer that had worked there previously, and the guy smugly said "well, if he's not there any more he was cut - not everyone can handle what we do".
It's been a few years since then, and from what I can tell they're still running the same website. I wish I could remember this guys name or the VP's name, just to see if they are still there.
I realize different organizations need different people/experiences but I see some obvious errors in management infrastructure and I'm trying to be not-pushy as much as possible while fully realizing there are good reasons for everything.
To my eyes, the things I'm proposing are simple and work almost everywhere else but they are still controversial, it seems.
How much should you be swimming against the current before calling it quits because we can't change anything? It's a general question, thus why I haven't given concrete examples for my situation.