141–150 of 172 posts
Lots of companies have stories about a few 'genius' developers who wrote the core of a system, and then left.
That's because it's more fun to develop something from scratch, than to deal with the maintenance of that system later on.
Rather than stick around and attend bug tracking meetings that go on forever, many of us quit to move on to the next cool project.
Earlier quoted context omitted.
Most decent companies have two pools of money. One for raises, and one for retention. The key here is, the manager has to really fight for it. If they believe enough in the employee to battle for the retention dollars, I've typically seen it go well. Here's the key, a lot of managers are too afraid, confrontation averse, or short sighted to make a fight for their employee.
I had a manager who used to tell, he was surprised how timid people at managerial levels act when it comes to fighting for their people. There are cases where there isn't even a competition for funds. All you need to do is ask for a raise and it passes through without any problems, managers just don't do it because they are too afraid of even making that very request.
They do not fight for their people, they get work and outcome from them to achieve the company objectives.
Most probably they are right if they consider who will give them their next career opportunity.
None of these 4 reasons (TD;LR: you waited until the exit interview, you assume mentors want to manage, you assume the natural ascension of developers is management and not higher-level IC roles, you aren't supporting them and their career) are why they quit. People quit because the modern, zero-loyalty, everyone-for-hire company does not provide a long term strategy for providing intrinsic motivation (autonomy, mast…
Earlier quoted context omitted.
Bonuses. Whoever works on this pile get's an extra $5000 at the end of every quarter. You only have to work on this pile for 6 months unless you volunteer for more. Companies tend to try everything except the obvious: more money.
Stuck on patching up legacy software right now, project has been dragging for four months already and the next years worth of projects in the pipeline are all just as shitty. Definitely enough to make me bored, definitely enough to make me buff up my resume in case any offers come along... even $5000 would go a long way in making me feel like what I'm doing isn't such an endless slog.
Earlier quoted context omitted.
> ...let the developers choose the work... This is much better advice than the whole article. The article seems to be conveying vaguely that developers want advancement, interesting problems, etc. The problem with this phrasing is that it makes a manager think about placation strategies. The root cause of the above is just poor tasking. If a senior developer says things need attention and keeps getting ignored, then…
I work at a company where developers choose the work. It's complete pandemonium. Nobody is listening to the product managers, the technical leads are doing customer interviews, the incompetent senior engineers have created a terrible mess for everyone else to deal with (and then moved on to new projects to create another terrible mess). The biggest issue is that engineers, especially ICs, absolutely are not giving a…
I meant that as part of professional development, technical leaders should have increasing say over the tasking of themselves and the team they're helping lead. There's lots of room to innovate and experiment on exactly how that works.
I'm thinking on the level of:
- If we haven't deprecated these old machines in 18 months, we're wasting piles of money
- This legacy code is too complex, but it will take some time to remove, so we need to start now
- Given the revenue numbers and the amount of maintenance effort we put into it, this part of the system and these features need to be removed. Let's split off a scrum of three for about a month to do it.
Back on point, here are a few other reasons:
- You give them no ownership over what they do, and do not encourage them to show initiative,
- You berate them for operating outside of a narrowly defined range of responsibilities,
- You spoon-feed poorly defined requirements to them,
- You isolate them from the customer and give them only second-hand information,
- You are excessively directive,
- You take a view that is excessively narrowed by an overly limited definition of what is the highest priority,
- You hamper them with bureaucratic processes that make it hard to get anything done,
- You continually break up their day with meetings and other interruptions making it hard to focus,
- Your meetings are undisciplined and run over,
- Your solution to any problem is to book a 60 minute meeting with no notice whatsoever,
- Your teams are too big, turning meetings into a long-winded and exhausting drama with everyone feeling they have to contribute and jockeying for position within some invisible hierarchy,
- You shut peoples' contributions and ideas down,
- When people spot problems there is no time or room in the backlog to fix them,
- Your agile ceremonies are bloated and tiresome, and your stand-ups are long,
- There is a constant need to engage in politics, especially if you want to be promoted or get a pay rise,
- The work is boring,
- It is necessary to build solutions for which other, viable, and considerably better/safer/more secure off the shelf solutions exist because of your aging systems/bad processes/excessive siloing,
- Many stakeholders and departmental siloing leaves developers trapped in the middle battling to reconcile conflicting viewpoints to reach a viable solution,
- Your teams are forced to operate in a way that is largely reactive,
- You manage by mob and/or by flapping and flailing around,
- At every meeting there is AV drama because everyone is using WebEx or some other crappy VOIP solution that leads to 5 - 10 minutes of buggering around for every single meeting,
- Cross-cutting concerns lead to even larger and more unwieldy meetings due to conflicting requirements across departments,
- The general atmosphere is conflict driven rather than cooperative,
- (Some of) your best developers are introverts yet you continually force them to engage in processes and practices that favour extroverts.
- Your office is a noisy and distracting zoo in which it is hard to concentrate.
I could go on (and on) but I'm beginning to depress even myself.
I think the number one reason developers quit is to outrun their mistakes. Lots of companies have stories about a few 'genius' developers who wrote the core of a system, and then left. That's because it's more fun to develop something from scratch, than to deal with the maintenance of that system later on. Rather than stick around and attend bug tracking meetings that go on forever, many of us quit to move on to the…
Well-designed systems may eventually grow into something monstrously unpleasant, not because it's "fun" to shit all over the pristine design specs but because it's most pragmatic.
Earlier quoted context omitted.
If you are actually in the UK, you have some amazing benefits that US-based folks don't get in the form of healthcare. I know, yes, technically, you're paying for it in taxes, but it's there for you all the time, regardless of your employment status or ability to pay for an insurance policy.
> If you are actually in the UK, you have some amazing benefits that US-based folks don't get in the form of healthcare. So? That's pretty irrelevant since any good developer job in the US comes with excellent health coverage.
Health insurance being so culturally tied to "employment" is ... very problematic.
Earlier quoted context omitted.
> If you are actually in the UK, you have some amazing benefits that US-based folks don't get in the form of healthcare. So? That's pretty irrelevant since any good developer job in the US comes with excellent health coverage.
And when you lose your job... you lose access to that "excellent health coverage". Health insurance being so culturally tied to "employment" is ... very problematic.
Earlier quoted context omitted.
How do you handle boring unglamorous but important tasks?
If a project is "important" then it should have business value. For some developers (including me), working on projects with significant business value is the definition of glamorous. Since there's significant business value, then you should be rewarding people for delivering that value (with bonuses and raises). If the task does not have significant business value, it's probably not actually important. A lot of main…
I want to work on what's most important for the business and our users. Having engineers pick whatever they find fun to work on sounds broken, but I'm also interested in if and how that can be made to work.