Bored people quit (2011)(randsinrepose.com)
randsinrepose.com
Bored people quit (2011)
http://randsinrepose.com/archives/bored-people-quit/
38 comments
I don't think a manager should be the one deciding deadlocked decisions. Managing a team is a full-time job, you don't have time to keep up with the codebase without compromising one or both. Promote someone you trust to tech lead and give them final say on technical decisions while they remain a coder, and concentrate on being the interface between your team and the company.
I'm borderline if managers should code or not, but as soon as you get to manage a team, and the job doesn't require it, do stop coding!
It is not your job anymore, and if over the next 5-10 years you start having a hard time talking to engineers, than maybe you weren't that good of a programmer to matter. Frameworks change, but general programming knowledge doesn't. Even if an engineer says something like "In rails 7, you can't splice the header from the body of the message stream sent over airsockets" as an excuse to not deliver and if you think it is important for the rest of the project, you should easily check google to understand what is going on, but you don't need to know rails 7!
It is not your job anymore, and if over the next 5-10 years you start having a hard time talking to engineers, than maybe you weren't that good of a programmer to matter. Frameworks change, but general programming knowledge doesn't. Even if an engineer says something like "In rails 7, you can't splice the header from the body of the message stream sent over airsockets" as an excuse to not deliver and if you think it is important for the rest of the project, you should easily check google to understand what is going on, but you don't need to know rails 7!
Once you stop programming, your skills will degrade like a musician who stops practicing, you'll eventually forget what its like to be a programmer like a parent forgets what its like to be a teenager. You'll lose your ability to connect with programmers, but hopefully by that time you are managing managers who manage programmers, or something like that.
Google can't fill these information gaps, and any manager who trusts Google over their engineers is probably a toxic one at that.
Google can't fill these information gaps, and any manager who trusts Google over their engineers is probably a toxic one at that.
A musician will have his skill decline, but his appreciation and understanding of music probably wont. I think this is the key point. Yes, after 10 years, the manager won't be as able to code something in the project (nor should he) but he won't just magically forget what O notation or graph theory is all about.
I think a better analogy maybe coaching. Some coaches were players before coaching, while others weren't, but their understanding of the sport isn't linked to them actually playing the sport.
I think a better analogy maybe coaching. Some coaches were players before coaching, while others weren't, but their understanding of the sport isn't linked to them actually playing the sport.
Not the same.
A coach would observe their players play everyday, and review their performance quite directly. Their bodies are not able to do it anymore, but they are "still in the game" so to speak. A bad development manager is often never looking at their programmers' code (or if they do, they might not understand it), only seeing and evaluating indirect results of their work. Even a good dev manager is not looking at their programmers' code very much, but at least they understand what is going on and are able to themselves in their programmers' shoes.
Organizational "visibility" is why it is so important for programmers to attend and speak up at meetings; the organization is incapable of valuing what they do directly. Also, "managing up" is the secret to getting things done with a non-coding boss.
A coach would observe their players play everyday, and review their performance quite directly. Their bodies are not able to do it anymore, but they are "still in the game" so to speak. A bad development manager is often never looking at their programmers' code (or if they do, they might not understand it), only seeing and evaluating indirect results of their work. Even a good dev manager is not looking at their programmers' code very much, but at least they understand what is going on and are able to themselves in their programmers' shoes.
Organizational "visibility" is why it is so important for programmers to attend and speak up at meetings; the organization is incapable of valuing what they do directly. Also, "managing up" is the secret to getting things done with a non-coding boss.
But that is exactly the point I'm trying to make. A coach won't be able to do a dribble (soccer) or sprint for the header goal, the same way a manager shouldn't be writing the unit tests or OAuth login, but both are involved in their fields and don't magically forget the rules of the sport or what OOP is.
I'm not advocating that bad managers should learn through google, but if you were a good developer and didn't program for 10 years, if the time came to decide between TDD or BDD for the project (though that should be a Team Lead or CTO job, not a PM) he should be able to brush up quickly. Maybe not decide if you should use Shoulda or xUnit or whatever, but have a general picture of what the developers they are managing are talking about.
I'm not advocating that bad managers should learn through google, but if you were a good developer and didn't program for 10 years, if the time came to decide between TDD or BDD for the project (though that should be a Team Lead or CTO job, not a PM) he should be able to brush up quickly. Maybe not decide if you should use Shoulda or xUnit or whatever, but have a general picture of what the developers they are managing are talking about.
What do binary decision diagrams (BDDs) have to do with TDD (test driven development)?
If this manager hasn't been doing development for 10 years, he is a lot cause. But this doesn't have much to do with programming, just being involved in building software. But in cases where their experience isn't fresh enough, they will have a tendency to either be static (we will write our web project in COBOL, because that is what I used to use dammit) or be very trendy to a fault (I heard post modern node-oriented programming was hot, let's use that for our compiler).
If this manager hasn't been doing development for 10 years, he is a lot cause. But this doesn't have much to do with programming, just being involved in building software. But in cases where their experience isn't fresh enough, they will have a tendency to either be static (we will write our web project in COBOL, because that is what I used to use dammit) or be very trendy to a fault (I heard post modern node-oriented programming was hot, let's use that for our compiler).
> What do binary decision diagrams (BDDs) have to do with TDD (test driven development)?
In context, BDD = Behavior Driven Development [1], not Binary Decision Diagrams.
[1] http://dannorth.net/introducing-bdd/
In context, BDD = Behavior Driven Development [1], not Binary Decision Diagrams.
[1] http://dannorth.net/introducing-bdd/
Is that related to Brooks' behavior-oriented programming for controlling robots?
Just like parents do not forget teenage years rather the experience of being a teenager is much different, so programming evolves and changes. But your point is still true, while non-programmers can appreciate the result, it is a job for professionals at thge top of their game.
This is the most valuable contribution to the discussion I've read thus far. Your points are concise and very insightful.
I would disagree that general programming knowledge doesn't change. While most of the ideas currently on the forefront of software engineering were invented decades ago, many of them have only hit mainstream very recently. While pure functional programming isn't used very often on large projects, current best practices prefer a declarative functional style whenever possible.
While a "for" loop may not have changed, someone who has only coded C++ may not understand why it's often the wrong way to iterate over a collection in modern environments. They might not understand why you'd use function parameters instead of inheritance, or lots of tiny single-method classes instead of one class that handles every aspect of a data type.
While these may seem like simple implementation details, they can lead to different approaches to problem solving, and conflicts over programming style that you might need to mediate. For example, if one of your group's goals is test coverage, then it would be helpful to have done some TDD, and know what characteristics are more or less conducive to testing.
While none of these ideas is brand new, there are a lot of teams that have only recently started embracing them, and a manager who hasn't kept up is probably not going to be a very good fit on a team that has.
While a "for" loop may not have changed, someone who has only coded C++ may not understand why it's often the wrong way to iterate over a collection in modern environments. They might not understand why you'd use function parameters instead of inheritance, or lots of tiny single-method classes instead of one class that handles every aspect of a data type.
While these may seem like simple implementation details, they can lead to different approaches to problem solving, and conflicts over programming style that you might need to mediate. For example, if one of your group's goals is test coverage, then it would be helpful to have done some TDD, and know what characteristics are more or less conducive to testing.
While none of these ideas is brand new, there are a lot of teams that have only recently started embracing them, and a manager who hasn't kept up is probably not going to be a very good fit on a team that has.
Especially this. Even worse: they might hear that functional programming is the new trendy thing, and for loops are passe. That you should always bury your control flow in a lot of small callback functions without the appropriate amounts of equational reasoning that must go with it, killing your ability to really debug your programmer. Or they might hear about TDD, and apply it in a very wrong way because they really don't get development very well. Actually, the only thing worse than a non-coding manager is a manager who tries to "keep up" without really being in the game.
A good dev manager is able to see the good over the fad.
A good dev manager is able to see the good over the fad.
Managers need to code. However, managers need to manage first.
"Management" doesn't always mean tell people what to do (it rarely does if you're doing it right,) Managing could mean protecting your team from all the boring shit work, it could mean making sure that your team's goals are in sync with other teams, it could mean making sure that people are prioritizing their work around what needs to be done rather than what would be fun to do, etc.
"Management" doesn't always mean tell people what to do (it rarely does if you're doing it right,) Managing could mean protecting your team from all the boring shit work, it could mean making sure that your team's goals are in sync with other teams, it could mean making sure that people are prioritizing their work around what needs to be done rather than what would be fun to do, etc.
Is there any distinction made between project management and people management in a startup? The developer manager must manage development first and foremost, it is a bit weird if they are handed project management responsibilities also, which can generally be handled by a less senior person, perhaps one who doesn't even code.
If there are other teams, I would assume we aren't talking about a small startup anymore. But even if we were talking about a small startup with one team working on a product, it makes sense to delegate project management tasks to someone in the team who isn't managing the team.
A developer manager should be able to protect their team from shit work because they know what shit work looks like in the first place. They should also understand the parts at a high enough level to make informed decisions, and they at least know who knows the details so they can get input from the right people when problems arise.
If there are other teams, I would assume we aren't talking about a small startup anymore. But even if we were talking about a small startup with one team working on a product, it makes sense to delegate project management tasks to someone in the team who isn't managing the team.
A developer manager should be able to protect their team from shit work because they know what shit work looks like in the first place. They should also understand the parts at a high enough level to make informed decisions, and they at least know who knows the details so they can get input from the right people when problems arise.
More the just frameworks change. More importantly, if you did not coded for 10 years, it is only that what you remember is outdated. It is also that what you remember is an idealized high level version of what it really was.
That kind of manager that bases his decisions on quick google searches without understanding whole system is the worst kind of manager. If there are trade offs involved and possible bad consequences in the context of your database, your search will ignore that.
Ultimately, "In rails 7, you can't splice the header from the body of the message stream sent over airsockets" is not level of detail non-coding manager should deal with. That is for the rest of the team to either propose other solutions or make it work with the rejected one.
The managers role is not to make technical decisions, his job is to ensure that other team members will help that "excusing" engineer to find solution. Managers role is to detect engineers seem to need help too often, but he is looking for pattern there - not one quick search over what might be controversial issue.
That kind of manager that bases his decisions on quick google searches without understanding whole system is the worst kind of manager. If there are trade offs involved and possible bad consequences in the context of your database, your search will ignore that.
Ultimately, "In rails 7, you can't splice the header from the body of the message stream sent over airsockets" is not level of detail non-coding manager should deal with. That is for the rest of the team to either propose other solutions or make it work with the rejected one.
The managers role is not to make technical decisions, his job is to ensure that other team members will help that "excusing" engineer to find solution. Managers role is to detect engineers seem to need help too often, but he is looking for pattern there - not one quick search over what might be controversial issue.
<quote>
The managers role is not to make technical decisions, his job is to ensure that other team members will help that "excusing" engineer to find solution. Managers role is to detect engineers seem to need help too often, but he is looking for pattern there - not one quick search over what might be controversial issue.
</quote>
That is exactly what I tried to say (maybe in the wrong way). A manager's job isn't to make technical decisions or help the engineer with code. It is to have an higher level view of the project, how it is going, and be able to help make it through. So, picking the rails 7 example, in this case the manager should be able to read about it and say, "Hey engineer X, have a chat with Bob in the frontend team, he may be able to help you out since he has experience with socket communication". Not decide to change rails to node because he read a blog post about how great node is.
That is exactly what I tried to say (maybe in the wrong way). A manager's job isn't to make technical decisions or help the engineer with code. It is to have an higher level view of the project, how it is going, and be able to help make it through. So, picking the rails 7 example, in this case the manager should be able to read about it and say, "Hey engineer X, have a chat with Bob in the frontend team, he may be able to help you out since he has experience with socket communication". Not decide to change rails to node because he read a blog post about how great node is.
I left my very first job because I, too, ended up bored and learning almost nothing. But I do remember that I was too scared to bring it up, because I thought there existed a possibility that the (very small) company might preemptively let me go, which would have screwed me up quite a bit. The most logical thing to do, in my mind, was to not let anyone know what I was thinking until I had signed a new offer letter and was handing in my two weeks' notice. Sort of like the prisoner's dilemma.
Was I wrong? (I hope I was wrong.) My manager was a great guy, and definitely not unreasonable. But at least from my perspective at the time, the stakes were so high. Was this just some stupid fear that doesn't actually reflect what happens in real life?
Was I wrong? (I hope I was wrong.) My manager was a great guy, and definitely not unreasonable. But at least from my perspective at the time, the stakes were so high. Was this just some stupid fear that doesn't actually reflect what happens in real life?
I've seen it happen: someone getting fired for pointing out how they'd like more work and are bored.
I think you just have to leave with an offer in hand, saying politely no to any counteroffers. But, always remember, move jobs like Tarzan, with one hand in the next vine before letting go of the current one. (Have an offer before letting _anyone_ know at your current job).
That being said, I encourage my employees to let me know if there is anything I can do _before_ it gets to that point. I believe in letting people move around between roles, jobs, and teams if it helps them engage better. But I'm a pretty private guy about not being happy at work, so I'm not even sure I'd take me up on it unless I framed it in such a way like "boy this other team is doing some cool stuff, can I help out?"
Something about the asymmetrical power relationship makes me very careful to not harm myself with my own actions: and having been fired once in a humiliating way really opened my eyes to how bad things can go if the person on the other end wants to be cruel.
I think you just have to leave with an offer in hand, saying politely no to any counteroffers. But, always remember, move jobs like Tarzan, with one hand in the next vine before letting go of the current one. (Have an offer before letting _anyone_ know at your current job).
That being said, I encourage my employees to let me know if there is anything I can do _before_ it gets to that point. I believe in letting people move around between roles, jobs, and teams if it helps them engage better. But I'm a pretty private guy about not being happy at work, so I'm not even sure I'd take me up on it unless I framed it in such a way like "boy this other team is doing some cool stuff, can I help out?"
Something about the asymmetrical power relationship makes me very careful to not harm myself with my own actions: and having been fired once in a humiliating way really opened my eyes to how bad things can go if the person on the other end wants to be cruel.
As far as I can remember, that's always been SOP in the workplace. Despite all these "new wave" models of employer/employee relationship, at the end of the day there is always a basic power imbalance between owners/managers and employees.
This article really hits the nail on the head. my first job out of college I was working for a big firm where I was bored. I kept getting told I was an exceptional engineer and was on a fast track for becoming a senior engineer. I was barely twenty two. I moved to a new job six months later where I was constantly challenged and learning new things and I couldn't have been happier.
i have a similar story, my first real company after college was a great place when i started, and then it seriously stagnated... i stayed 5 years in all, but in the last year i had no active project, just minor maintenance tasks... people were also getting laid off left and right as well..
> The reality is that someone is going to tell you they’re bored quietly and when you least expect it. They’ll tell you halfway through your 1:1 and they won’t use the word bored. They’ll say something innocuous like, “…and I really don’t know what to do next,” and you’re going to blow right by the most important thing they’ve said in a while because you’re worried about your next meeting.
I see a parallel between this quote and a supervisor or co-worker stating some other co-worker "doesn't understand", which when translated to cold, honest English becomes:
"[co-worker] is antagonistic, aggressive, rude and stubborn. I do not want to confront [co-worker] regarding this issue because I want to avoid the hostility that will be thrown back at me, you will have to deal with [co-worker]'s hostile behaviour all by yourself because I am a stinking coward and want to brush this problem under the carpet."
I see a parallel between this quote and a supervisor or co-worker stating some other co-worker "doesn't understand", which when translated to cold, honest English becomes:
"[co-worker] is antagonistic, aggressive, rude and stubborn. I do not want to confront [co-worker] regarding this issue because I want to avoid the hostility that will be thrown back at me, you will have to deal with [co-worker]'s hostile behaviour all by yourself because I am a stinking coward and want to brush this problem under the carpet."
His post from today, "The Diving Save" [1], is also quite relevant to this: how do you keep someone, once they've started to check out?
[1] http://randsinrepose.com/archives/the-diving-save/
[1] http://randsinrepose.com/archives/the-diving-save/
One way is to give more interesting work and/or work that is a natural possible progression in the employee's career. That technique helped my company woo me over into staying, along with a modest salary bump (although I was seeking much more - career progression mattered a lot to me).
From a personal perspective - I've turned to the quit mentality due to boredom after my first job after not having enough to do, and at my second job I converted over after immense deadline pressure for half a year when combined with significant underpayment (extreme frustration).
The best pre-emptor would be to be proactive in addressing these problems. If your company is exerting too much pressure on developers, then you probably did a poor job hiring enough employees or incentivizing them enough - I'm looking your way startups.
From a personal perspective - I've turned to the quit mentality due to boredom after my first job after not having enough to do, and at my second job I converted over after immense deadline pressure for half a year when combined with significant underpayment (extreme frustration).
The best pre-emptor would be to be proactive in addressing these problems. If your company is exerting too much pressure on developers, then you probably did a poor job hiring enough employees or incentivizing them enough - I'm looking your way startups.
> If your company is exerting too much pressure on developers, then you probably did a poor job hiring enough employees or incentivizing them enough
I've noticed this to be a huge issue when it comes to large companies who try to defend the situation saying we are "lean" and reduce forces by "cutting the fat." I'm currently in a situation where I've become "The Guy" for two entire product lines and its gotten to the point where they keep tempting me with "You'll be on Next Generation SOON". But soon, in my eyes, will never come because I'm a single Engineer maintaining hundreds of thousands of lines of code, code that deals with an OS no one else uses, in build environments no one else uses.
What I use to think of as job security has become a pill that induced boredom.
I've noticed this to be a huge issue when it comes to large companies who try to defend the situation saying we are "lean" and reduce forces by "cutting the fat." I'm currently in a situation where I've become "The Guy" for two entire product lines and its gotten to the point where they keep tempting me with "You'll be on Next Generation SOON". But soon, in my eyes, will never come because I'm a single Engineer maintaining hundreds of thousands of lines of code, code that deals with an OS no one else uses, in build environments no one else uses.
What I use to think of as job security has become a pill that induced boredom.
I would be less inclined to be saved with a dive since all I'll be thinking at the back of my mind is that I'm (to quote the article) "working at a company where folks apparently need to resign in order to have a real conversation about their roles.".
As with everyone else, after reading I've realized I'm extremely bored at my current situation. The one thing I'm having difficulty taking away from it all is what to do about it. I work for a big company, been here for a decade, have become "The Guy" for two major product lines and have never really had a Team. In a decade I've done two...yes two projects. Each one all written by me, application code, kernel drivers, building a root file system. Hundreds upon hundreds of hours generating thousands and thousands of lines of code. I'm bored because I'm given a project and because they will not fund additional heads (I'd love just one but really should have 3 or 4) these projects take 3-5 years to complete. The beginning is interesting but after a few months it comes down to "Implement these 200 API calls" which gets old really really fast.
At a startup there are tons of tasks to get done and not enough people so you can easily jump from one area of the company to another. Your manager can say "Joe is getting board doing X, but Y needs to be done and its completely different." But what do you do when your job doesn't have other areas for you to jump to? We have different areas of the business but at this point I'd have to take a demotion to move...or become a manager and not code anymore.
I guess I've got more of a gripe than an actual comment. And I know a lot of people post about startups and small companies where change can actually occur. Sucks that I have to give up stability to get interesting work.
At a startup there are tons of tasks to get done and not enough people so you can easily jump from one area of the company to another. Your manager can say "Joe is getting board doing X, but Y needs to be done and its completely different." But what do you do when your job doesn't have other areas for you to jump to? We have different areas of the business but at this point I'd have to take a demotion to move...or become a manager and not code anymore.
I guess I've got more of a gripe than an actual comment. And I know a lot of people post about startups and small companies where change can actually occur. Sucks that I have to give up stability to get interesting work.
Seems pretty on target, though it may be too late by the time you notice a change in their daily routine (the first bullet point), as this may indicate that they've already begun going on interviews. Perhaps it's better instead to ask the employees periodically for their feedback, rather than wait until you notice a bad sign.
And when they give you their feedback, listen. They may only tell you once.
Or, if they worry about getting laid off, they may not tell you at all.
Yep, lots of people work for little people at BigCo.
I think he means a change in routine caused by them simply not enjoying the work anymore, so they come late or leave early or take long breaks etc.
And yes of course digging for signs doesn't beat asking by far. Ideally performance reviews can fill this role (sadly, at least here, too often those are treated as just a legal obligation where the only practical goal is to discuss and most importantly document some complaint, no matter how small, so that just in case the company later decides to fire the employee, they already have a file with "evidence" that you were underperforming for a long time).
And yes of course digging for signs doesn't beat asking by far. Ideally performance reviews can fill this role (sadly, at least here, too often those are treated as just a legal obligation where the only practical goal is to discuss and most importantly document some complaint, no matter how small, so that just in case the company later decides to fire the employee, they already have a file with "evidence" that you were underperforming for a long time).
Agree with this post, but would go further: if someone feels that they are not contributing in a way commensurate with what they think they should be able to contribute, then the reason- whether they are bored or not, and it is their fault, or someone else's, or no one's fault- they will be unhappy. Challenging is not as important as fulfilling.
My problem in my old job was due to boredom. But it was more than that - I was bored and management didn't really take heed of what was wrong despite the feedback that I have been giving at my annual performance review (where I did extremely well) and monthly meetings with the line manager. Even if I had the education and work experience with certain projects, politics ("X's department is doing that") and That's-not-your-day job-isms" got in the way. So in the end, I got bored and quit.
I'm so bored I've been unemployed all my life
[deleted]
For me, this is the money quote. Like rands, I've gone back and forth on this over the years as well, but I do strongly believe that you cannot effectively manage a team if you do not understand what it is that they do, at least at a high level.
You don't need to be as good at coding as the engineers who work for you, but you must know enough to empathize with them, and to help mediate dead-locked discussions.
I'll admit that there are exceptions, and effective s/w managers who can't code do exist, and I'll also admit that finding such managers is probably not a scalable task, but I feel it's something that every company should strive for.