Hacker News new | past | comments | ask | show | jobs | submit login
What to do when tech jobs go bad (medium.com/xevix)
196 points by veidr on Feb 19, 2018 | hide | past | favorite | 126 comments

I've seen this at the most basic level of contracting. To me, a lot of these problems come down to cost.

I've contracted with a dozen startups and small businesses. Most of these companies will find a young developer charging between $20/hr and $50/hr and have them start coding on their new app/website idea and feel wildly optimistic when they see the first 80% of the project come together.

Then it's time for the edge cases, and because there aren't any senior devs on the project, handling those edge cases introduces bugs. Weeks and months pass, and the project that looked like it was a surefire success descends into development hell.

But the company never fires the developer. The developer actually quits from being over stressed. Then the company goes looking for a new developer, who tells them they'd be happy to build their software for $20/hr-$50/hr. The new developer comes on, looks at the codebase, decides all of it is crap, and recommends they start over.

The new developer finishes 80% of the project in the first week.... rinse and repeat.

The company should have hired a developer or firm with a record of success, with actual, running software out in the wild. How they achieved that may or may not line up with the ideas in the OP, but at least the company would know exactly what they're paying for.

I've described this phenomenon to many-a-manager as "assuming that all progress is linear." It's not; in fact, linear progress is extremely rare in my experience. Usually, a "big bang" of progress happens on a project, whether at the beginning or at the end.

Recently, I was implementing Pivotal Cloud Foundry for a client. Everyone was assuming PCF would deliver incremental and linear amounts of value during implementation. I had to keep telling folks, "No, it doesn't work that way. PaaS is only valuable at the very end of the implementation, when all the technology is ready and the team has been trained."

I think the XP movement was, fundamentally, an attempt to treat coding as a performance piece, where progress IS close to linear because of the order you tackle problems and the way you attack them. You telegraph and you telegraph and in the end if anyone is surprised then it's because they weren't paying attention or were delusional.

It's part of why I maintain that it's much better to be 5-10% over every estimate along the way but maintain your velocity indefinitely. Better for people to be a little disappointed in you now than to drop a giant bombshell on them later. It's not a popular opinion, but it does work if you have a team with the fortitude to stick with it.

Agreed on the linear progress. I’ve been working on implementing various parts of a PaaS/SaaS solution for the past few years. I’d add that the implementation is only as good or mature as your processes. Sometimes the solution and process must mature before you realize the full value.

agreed - there's a network effect to various bits working together, and it's not apparent until they're all there.

it may be linear progress from "lines of code" or some other metric, but there's a point (or usually a few) at which peoples' perspectives on the project changes.

I've hit this a couple times on recent projects, and it's usually tied to some new UI stuff hitting people. Usually, they've seen all the various pieces, but until they can click-click-click through end to end on a process, they don't care, or get frustrated and mentally tune out of that part of the project.

At my company managers have started referring to engineers as "resources". I think it reflects the attitude towards the workers. An engineer is just a number on a spreadsheet and there is no difference between them. If something goes wrong you just hire more resources as cheaply as you can.

"I bought my boss two copies of The Mythical Man Month so that he could read it twice as fast." - @rkoutnik


When I was a lad there was a bit of advice when interviewing called the Dilbert Index. When they are walking you through the building for your interview, check out how many Dilbert cartoons people have posted in their cubes. I believe the advice went on to say that if you see more than 2 you should be worried, but maybe it was a higher number.

I'm starting to believe there's a similar rule for how many copies of MMM you see on the bookshelf. I've seen as many as 5 stacked together, and that place was whackadoodle.

My own theory is that the morale of a workplace is inversely proportional to the number of Dilbert strips hung on the cube walls.

I use the Dilbert-o-Meter as a measure of how bad the job is once you're actually in it - how many Dilbert cartoons do you witness play out in real life exactly as in the strip. I had this happen in my first job out of university, watching strip after strip happen in front of me without any irony. I lasted three months in that job before I quit.

I now use the same metric to decide when to quit a job and move on. I'm now at a startup, and keeping a close eye on its inevitable transformation...

Somebody once told me in a meeting: "The company was going to deliver their presentation, but the resource had a baby."

We really need to end this craziness.

I'm curious if it has coincided with things going downhill at your company? It seems like this is in general a red flag, but I only worked one place that they referred to people as resources.

It was a terrible place to work if you cared about what you did at all as you never got to finish anything. They shuffled you around like cards, different teams, different buildings, different projects, basically rearranged things based on the whims of those currently with the clout as a way for them to increase their clout.

It's more prevalent at the IT department and they are a complete disaster. Boatloads of architects and managers not doing any work but farming everything to offshore developers. I think in my department it started with the opening of an office in India.

A resource is someone who rewrites your source.

I wonder what that tells us about the purpose of the Human Resources department....

"The first 90% of the code take 90% of the time. The remaining 10% of the code take the other 90% of the time".

If you're lucky and know that this is the case. If you think you're actually "90% done", you're in for a world of hurt.

Do you ever get a strange visceral feeling when you see a video of someone about to have a really bad accident? Like your extremities are trying to crawl into your abdomen?

I get that feeling when anyone cheerfully exclaims that we're 90% done.

Thanks for the original quote. I'm more used to hearing it as productivity: once you think you're 90% done, you're halfway there.

the pace of making changes grinds to crawl as codebase becomes larger and more complex. eventually the time spent trying to understand code, figure out what changes can be made safely and paying down tech debt outweigh the time spend making measurable improvements.

key things that help - focusing on extensibility/abstraction in areas of code that will require ongoing changes. This is where you most need experienced and talented engineers. - maintain testing discipline - conservative dependency management and picking the right battles between DIY and open-source - creating periodic blocks of time for engineers to refactor software or architecture.

Fairly early on I worked on a project that was size constrained due to pretty severe storage restrictions on the target device. Within a year we hit a point where every feature we added required that we first make space for it by winnowing down the rest of the code. Sometimes that was making the code more sophisticated, but most of the time is was more of a Antoine de Saint-Exupéry sort of expedition. It was a constant battle but in retrospect it's some of the most rewarding work I've ever done.

After that project I intuited that projects had a maximum complexity after which the wheels fall off, so to keep a project growing past that point you have to remove accidental complexity before adding new intrinsic complexity. For the limited sample size I have direct or indirect access to, this really seems to hold. And in fact someone told me that RPI teaches something very close to this in a required class for one of their Masters programs in CS.

Abstractions do not fix this problem. They put it off until the next performance emergency happens. It's an avoidance tactic and kind of paints you into a corner. Ultimately you're not looking for an abstraction (I mean, it is, but so many bad things are also abstractions that I hate to use the word for this situation). You're looking to model the problems actually being solved. You're looking for the truth.

I like to draw a distinction between abstraction and automation as architecture ideas.

Abstract stuff is "just" more abstract and adds a new concept on top of the old. Abstraction makes the coder feel all grown up and maintain the daydream: "once it's done building the features will be so much easier."

Automation is the part where we say, "this is repetitive and hard to keep track of - so make the computer do it." Automation creates leverage. And sometimes you need a truly novel abstraction to automate successfully, but in most instances you only need the same old 70's era programming constructs wired up a bit differently. Which does lead to dropping one abstraction in favor of another, as you allude to.

Even if you get into, "well we need to Optimize it, we can't just do the simple and straightforward thing" you can start automating the trivial, repetitive optimizations and get into the business of generating code. And that can be abstract, but it doesn't have to be - you don't have to incorporate a whole suite of compiler checks or a runtime model, the "compiler" can be a FSM that emits source code - but it'll be automated, and you can add the interface and checks to it that are most relevant to the problem, and make the output look human-readable to some degree.

Edit: another benefit of this approach is that your initial coding environment truly is "implementation detail" since it's the starting point and you just add the leverage you need from that point rather than feeling obligated to use the officially branded abstractions.

“The company is a family.” No it is not, and if it were, many companies behave like an abusive parent, where the child keeps giving, and the parent keeps expecting and punishing.

I often wonder what happened to being professional. If someone ever says they prioritize working for actual money over being passionate about changing the world while basking in the vision of some VIP on the board that's like admitting murder. I see this mindset more and more in non-tech jobs as well.

This one bit me. When I was fresh out of school I worked for a "from the garage" startup. I was naive and working around the clock nights and weekends, and the owners told me to think of it like I was part of a family. I fell for it, thinking "we are all in this together" and using it to justify the stress and hard work.

When the company succeeded, due in part to the systems I built and designed from scratch, I was unceremoniously asked to leave a few weeks before the transaction closed for many millions. I was asked to leave because as we drew nearer to a sale of the company, I had the nerve to ask for the company to put on paper how I would be a part of that transaction, since I had been verbally promised that "a rising tide floats all boats" and I would be rewarded handsomely for my work. Mistake #2 of 1000 then, accepting a verbal agreement over one in writing.

In the end, when I asked about getting it in writing so close to the sale, I was asked to leave. When I said, "but, you told me I was to think of this like a family", I was told, "we thought you were smarter than that".

That episode did a lot of damage, and I never saw anything meaningful in terms of compensation- the owners got fabulously wealthy.

I made many mistakes then, and I could have pursued legal action, but it was all too painful.

Since then I always try to insulate my feelings and remember that in a professional setting I can always do my best and be professional, but to always remember that to others, it really can be "just business". It's important to keep some distance and avoid emotional abuse at work, both doing it and receiving it.

It's not to say we can't be friendly, but just to be professional, honest and ethical in the workplace, always.

Edit: I meant to mention, that in this job, I was working for the "changing the world part", but when I saw the imminent sale coming and I had nothing, felt I had to ask if I would be a part of it. Back then, it was a mistake for me as well, to assume that I was going to do good and get handsomely rewarded and expect that the two would come together. I think it can happen, but I learned the hard way how to compartmentalize changing the world and getting paid with simply doing necessary work to get paid and survive.

And so many people out there wonder why engineers are hesitant to work for startups now, and demand high salaries.

I do also feel that the founders in that story should be named and shamed. There is absolutely no excuse for that kind of behavior. They should never be able to do that to anyone ever again.

I do completely empathise with the parent, but you also have to consider it from the other perspective.

If those type of employers could get "named and shamed" based on someones verbal only, then it would be a dangerous society we live in. On the other hand, if it was written down, there would have been no problem in the first place.

I believe that naming and shaming unscrupulous founders who fuck over people like this would encourage more to codify these agreements in writing from the get-go.

The company is the one that made the verbal agreement, which they could have written down at any time. The company is the one that abused it's power, and most importantly, the trust of the employee. To me, that is an incredibly heinous act, which should come with draconian punishments.

The fact that you're saying "the company is the one..." and that they should suffer draconian punishments after reading an anonymous internet comment is exactly why we shouldn't treat verbal contracts seriously.

You don't know if the company did anything.

A company that's on the up and up will make sure the contracts are in place. One that is not will rely on people forgetting their verbal contracts.

And my draconian punishment remark was directed at founders who fuck over their employees in general. Violating that trust should carry extremely heavy penalties, to the point where you are much worse off than if you didn't.

In this case, maybe. But I am talking in general. In general we don't know who to believe, founder or employee. I would imagine there would be just as many unjustifiable disgruntled employees than there are unscrupulous founders. Therefore we must maintain the resumption of innocence until proven guilty. I.e In writing. The moral of this story is that you don't invest money or time in words, and the parent will likely have learnt a costly lesson.

I am sorry that you have to go through that. I can understand the disappointment and indeed every episode in life should make us stronger when we look back. Personally I would sue the owner. A verbal promise can be argued and it makes total sense for me to embarrass an adult like this owner.

I was in a similar situation, and another aspect to this issue is - if the company is large enough - HR departments who put on events or team-building activities or otherwise try to encourage a sense of how great the company is and how great it is to be part of the company; e.g., company potluck this Friday! There is nothing wrong with these things, per se, but what is disturbing is how this HR "PR" does try to give this sense of "belonging" and "family" which is ultimately at odds with the bottom line of the business. No, HR dept., unless you have unusually altruistic owners, the business is not there to make one big happy family; it's about the bottom line.

Name and shame buddy, we need to know who the toxic abusive employers are. There is no such thing as professional decency in this situation. Exploitative capitalist behaviour needs to be dealt with in unconventional ways.

Having worked for nothing but large-ish companies, I tell everyone I can "The company will never love you like you might love it".

Take that vacation. Take that time off. Ask for that raise.

Tomorrow someone you've never met (and may never meet) might circle your name on a list of employees to be laid off. Never knowing what you did or didn't contribute. Or how dedicated you are.

What happened to being a professional? Business people discovered it was cheaper to pay people in short term good feelings than in money is what happened.

Yeah, the saddest part is that people who bought the bullshit are happy to maintain the system by ganging up on those who try to be professional and keep a clear line.

Furthermore, how many stock brokers go on teambuilding retreats?

When I hear "this company is a family," I say, "You're not supposed to go into business with family."

When I hear “this company is family” I think

“Manson Family” Or “mafia family” Or “Addams Family”.

It's easier for managers to provide poor benefits, no raises/advancement/career growth if they tell themselves people work for them out of passion and love.

Great article. The one that hit home for me "One lone engineer on a big project silo’ed away".

Was on a project where we had multiple applications. The team had a new employee code an entire system as a prototype but then it was decided to put it into production. Nobody ever reviewed this code, and that engineer told me himself that the code was crap. He left the project to get away from this code and I inherited a mess, with nobody to ask questions from.

To make matters worse, the entire company relied on this system and there were about 20 regular users of this system. I was responsible for handling all of their feature requests and support which was often. Many bugs I fixed were extremely challenging edge cases, and there was zero appreciation for the complexity of many of these.

My manager was telling others at the company the code was solid, and it's "just python code" which can be figured out.

I notified the company I was leaving and they begged me to stay. Even offered to "release" me and hire me at a higher salary under another manager. The only issue was I would be required to support this same project.

My manager refused to give me a release date so I had to call HR and tell them I needed to leave at any cost. Pretty sure it's a disaster there since I left.

This happens a lot with non-technical founders hiring contractors or employees.

At first, the goal is “build a prototype,” then it’s “make this an MVP,” and then finally “what’s left to get this to production?”

I don’t blame founders for this; I blame the programmers, especially if they’re consultants. This is a symptom of failure to manage expectations of stakeholders.

As a developer, your job is to show the stakeholders what the tradeoffs of different decisions are, both in terms of immediate time to results, and technical debt. If you hear “make a prototype,” you better ask for a projected lifetime of the prototype, and discuss with the stakeholders the tradeoffs of quickly building a prototype, making sure they understand it could mean more work later to productionize it, in exchange for less work up front.

Also as a developer, you should realize that nothing is ever a prototype. Don’t use “it’s a prototype” as an excuse for writing unmaintanable and insecure code, because eventually someone is going to want to add some features to it. Good luck telling the stakeholders after three months of building a prototype that you need to start from scratch because the code is awful. This is especially difficult if the prototype looks like a fully functioning product (with minimal features) to the stakeholders, but you as a developer know that under the hood it’s completelty unmaintainable.

It’s better to take the time up front to put in place whatever you need to write quality code, than it is to take shortcuts and write bad code. A good developer will be able to explain this to a stakeholder, instead of caving under pressure to rush a prototype.

No, I completely and fully blame the managers/founders for this. No matter how much you try to drill into their heads that this is throwaway code, once they see something, they get excited, and say "Ship it!"

If the tradeoffs were valid and fully understood, the stakeholders would not logically come to the conclusion to “just ship it.” The only person who can explain the tradeoffs to them is the developer.

Therefore, if they say “ship it!”, they are either wrong or missing information.

If they are missing information, the developer is at fault for misinforming them of the tradeoffs necessary for decision making.

If they are wrong, then either the developer has cited irrelevant or incorrect tradeoffs, or the developer made valid points but the stakeholders understand the tradeoffs and are willing to accept them.

Or, the managers are idiots.

You're trying really hard to bring this back to always being the developer's fault, and you're ignoring that, many times, management just doesn't listen. You can explain until you're blue in the face, but if they don't want to listen, nothing will make them do so.

> you're ignoring that, many times, management just doesn't listen

And ignoring that, almost all of the time, the programmer has very little power in these sorts of transactions.

Everybody is an idiot about most things. As an expert in a domain, your job is to help non-experts be less of an idiot when making decisions that depend on things you know better than them. You won’t get very far with a stonewalling attitude of “well, the manager was an idiot.” You need to establish trust and a working relationship where you both listen to each other.

Making my boss less of an idiot is something outside of my control. I can tell them "don't do this" over and over again. If they do it anyway, how is that my fault?

In an ideal world, sure. But I live in the real world, where there are lots of managers that are just plain shitty, and no amount of explanation will change their mind. It just does not work at all. Blaming the developer is not a reasonable thing to do in that situation.

Unless you're paying top dollar for contractors, what you describe is way beyond the job duty of typical contractors brought in by non-technical founders who have no idea what they're doing. Even technical founders with a lot of experience make this same mistake. If you're not paying seriously high money, you might think that this is something you're paying for, but it's not. Someone at an overseas sweatshop isn't going to push back on a request for a prototype. It's not part of their job and it sure as hell is not in their own interest. People get what they pay for and most of the time, people who hire contractors without proper oversight are just burning money and have no idea what they even want to pay for, let alone what they've actually bought. Intelligence cannot be contracted for by stupid people.

Always write quality code or when bugs occur or new feature requests come up, they will call you. If you wrote something awful now you have to support it.

But you cannot blame the developer. Many app are prototypes to get them over a certain point to get funding. What happens is the technical debt is never paid and you are forced to scale the prototype while adding new features.

I don't think your solutions will work. It's impossible to get time estimates right for building software. Too many variables in solving the problems, not only in writing code and testing it, but also including open office disturbances and meetings.

I understand product owners and businesses wants estimates but software engineering is not making a car. Forcing programmers to estimate their every task makes for a very bad work environment. They are not robots.

My solution to this has always been to break down the units of work into smaller pieces. Super small. Painfully small.

It requires more project management, but it's much easier to quarantine problems and explain them to stakeholders.

My rule of thumb is 4 hours. If you think it will take longer than 4 hours, it should be broken down. Ideally, most tasks will have estimates of 1 hour.

That way, when a 2-hour task requires 2 weeks to complete, you can point to the specific task and its challenges. It provides an easy explanation for why the release was late, why the requirements were too ambitious, etc.

This is micromanagement. You're describing micromanagement.

Engineers do not need to be managed down to the hour. Good grief.

This gives me PTSD to a consulting job I had as a web developer where every 15-30 minutes the project manager would come up to my desk to ask what I've been up to and what I had achieved (in the last 15 minutes). He'd also get upset when the feature I was working on wasn't finished yet since the last meeting.

I've personally witnessed the VP of product stand over our senior engineer's shoulder while he tried to debug some serious bug that we couldn't reproduce in dev/stage for hours until it was done. That same engineer also had the CEO stand over his shoulder and actually ask "You don't mind if I stand here and watch do you?" The same CEO constantly brags about his "10 years of experience building companies with successful exits"(10 years of experience vs 1 year of experience ten times), and calls his company the "Amazon of the south". Reading this article gave me flashbacks, but it does help to know that it wasn't just that company.

With an interruption every 15 minutes, sounds like you would never reach a state of flow.

In my own experience as a software developer, it is incontrovertibly true that the smaller the unit I/we use to break things down, the more accurate the resultant time estimate becomes.

However, as padobson notes, there's an overhead associated with breaking complex things down into smaller units. There's a point at which it becomes counterproductive.

I feel like I have, over the years, sometimes crossed that line.

(And, other times, not gotten close enough to that line and been surprised by weeks/months of schedule disintegration.)

I wonder if this is because one never rounds down to zero, so that finer grained estimates automatically pad themselves. I've noticed that estimates run higher and higher, the longer the planning meeting lasts.

I was over a project and part of releasing the next feature, I decided that it was best to tackle some technical debt based on my now knowing a better way than I did when I first implemented the system - basically bringing it up to our current standards that involved a lot more automation and other features that would make my life easier.

I wrote down in detail all of the tasks involved just to help me estimate like I always did. By this time we were transitioning company wide to scrum.

Every task I put in was scrutinized by the contract “scrum master” as it wasn’t part of the MVP even though I knew it wouldn’t affect the schedule since I had prior work I could base it on.

The rest of the dev team had the same issue. I got tired of fighting and the scrum master was getting in our way. I told them to do what they thought was right and run it by me first if it was anything major. None of the things we were trying to do were customer facing, they were all backend architectural things.

I tried to fight the good fight but then had the epiphany - I didn’t have to. I’m the dev lead, I do the code reviews and no one higher than me will be looking at the code. I told them not to be detailed in the how within our project tracking system.

Really love your comment as it strikes home. Just transitioned to scrum last year and have a terrible PM I mean Scrum Master. No help at all just and he only makes sure Scrum meetings happen. Also he’s way overconered about velocity and story points.

Another senior dev told me the same advice you realized. Now we just create more generic stories. He’s stared to go story by story and wants to know how it meets a business objective.

Our stuff is extremely customer facing and time critical. I welcomed Scrum over Agile but a bad Scrum Master can kill the benefits.

Smaller tasks have less accurate estimates. If you say something takes 1h and it actually takes two days that's ~16x as long or a week long task taking 4 months. All it takes as a small corner case or odd bug that you did not consider and suddenly your estimates are worthless.

The only thing that makes small estimates seem better is the worst case tends to be less time, but overall they don't help.

An estimate is not a single number. Rather, an estimate says “it may take 1h if everything goes well, it may take 16h if things go bad.” This is then followed up with “at 1h, I’ll update with either a done or a revised estimate.”

Giving single numbers for an estimate with uncertainty is bad for all parties.

Additionally, with experience one can get better at giving estimates with less uncertainty for well known tasks and recognize the uncertainty for other tasks.

That's not relevant. Low / high estimates can be written in this form: X hours +/- Y%. 1-3 days seems wide but it's just 2 +/- 50%. 1 hour or 2 days ~= 1 day 1 hour +/- 90%.

AKA Y is much higher when you deal with low hour estimates.

This is most noticeable when you have lot's of tasks. If you think 200 tiny tasks may take 1 month or just over 1 year that's an almost useless estimate.

It's not micromanagement. It's planning. There's nothing wrong with those tasks having no-user facing changes, or giving all the tasks to acheive a higher-level goal to one developer. However, going in and making those tasks forces you to think over the problem properly and come up with a game plan.

If you don't know a given approach will work, sometimes that's best to timebox some experimentation time (say an afternoon), but then you can also say to your PM/EM 'ok, we need a little time to work out how long it's going to take', and decisions can be made accordingly as to priorities.

Very little of being a software engineer is about writing code. That's just typing. The skill is being able to come up with a coherant plan to solve a problem. That's why architects don't tend to write a lot of code.

It's actually not micromanagement. It's micro-documentation, which provides more autonomy to the developer, not less.

The micro-tasks I'm describing go into a project management system. They are either assigned to or picked by developers who complete and document the micro-tasks on their own. Because the tasks are so small, there is almost no management of developers required.

Finally, it's trivial to find out where project estimates went wrong, because any hidden challenges are well-quarantined in the micro-tasks. If the task isn't well documented, it's still pretty easy to go to the developer and find out why it took longer than estimated.

In no-developer-experience-manager's worldview, this is actually a good idea.

If development was so easy that a manager who doesn't understand programming can break developer tasks down into small chunks - we'd live in a completely different universe!

In reality, management breaking anything down into smaller tasks, instead of people who will actually do the work, breaking things down, is going to lead to ZERO architecture and a shit codebase, 100% of the time.

That's if you're lucky and the project is a clean slate.

Existing codebases are full of code smells that'd take days to comprehend, days to chase down and comprehend what the actual requirements were/are because those are never properly documented, and then re-write that 'micro-task' so that the next developer doesn't have to spend their days in hell.

Oh, this'd need to now be tested, there'd be new bugs, and those would need to be fixed also.

So instead, in the real world - your micro-task gets handed down, the developer doesn't bother understanding what the existing codebase is doing, they just patch it until it works, contributing to the unmaintainable piece of garbage that all developers with any self respect left in the world hate.

Since only the brave/crazy ones will say 'this micro task will take 2 weeks instead of 2 days because the existing code is garbage', those brave ones will get replaced by those who will say 'yes, 2 days'. Your project will need more and more time per task, and more and more developers doing maintenance, but the managers will continue reporting successful micro-tasks completed on time!

I've just described corporate programming and how you're directly contributing to the hell that it is.

> In no-developer-experience-manager's worldview, this is actually a good idea.

More precisely, a no-development-management-knowledge manager’s worldview.

While obviously development experience can be a source of development management knowledge, there's no reason it should be the only source, and development managers ought to be screened for job skills as much as developers are.

I don't see any reason why it shouldn't be the only source - even at McDonalds, managers graduate from being regular burger flippers.

That's why McDonalds works, and software development is a perpetual disaster - McDonalds understand that to manage even something as simple as flipping burgers, you need to have done it yourself first!

It's the arrogance of business school management that's responsible for a great deal of turmoil across many areas of everyday life. Just imagine going to school for something that's not difficult, to 'learn' how to boss people around. For good pay!

Isn't that the dream of every non-creative, lazy, half-wit you never want managing anybody ever? Yes... yes it is...

This is a recent phenomena on a mass scale and it isn't going to last - getting high rank without having earned it has always been a complete disaster, just look at any point in history.

In reality, management breaking anything down into smaller tasks, instead of people who will actually do the work, breaking things down, is going to lead to ZERO architecture and a shit codebase, 100% of the time.

This is just another way of saying management is incompetent. There's no project management strategy that is going to overcome incompetent project managers.

So, if a developer takes too long developing the pre-defined micro-task which you've assigned them, you have to followup with them and report on why a micro-task took too long?

If this isn't micromanagement, what would you define as micromanagement?

Exactly, I see Devs in our company having small meeting all the time to discuss the most ridiculous things that you could imagine... if Eng ever get micromanaged like this, I'm out in a month.

A month is too long to wait. Break it down into smaller units... ;-)

I think some managers just don’t have enough to do so they make work for themselves (and everyone else). Like a border collie with no sheep to herd, they will start herding ducks, children, etc.

Hey, this post (and all of your posts) are marked as dead. ~I'm not sure why~

Please, help us understand how having a 60 item worklist per week is "micro-documentation". I'm sorry, but you haven't really worked with or had training from real-world engineering managers.

For the engineers, and yours, peace of mind and progress -- please spend some time with stellar execution managers that understand software development is a people problem, not a project management problem.

Good engineering managers (preferably someone who knows how to write code) are going to be able to break tasks down effectively. So yes, it always starts with people.

And I agree with you: talented people, be they managers or developers or janitors, will be able to overcome any process or planning shortfalls.

But there's no difference between what I'm describing - a project manager breaking down features into bite-size bits of work - and a developer taking on a single feature and writing down TODOs in code, on post-its, on a white-board, or in the comments of the project management software.

The difference is one of documentation and communication to stakeholders - which is the PRIMARY problem with software estimation. There are ALWAYS unknowns in software. A team leader needs to be able to go to his boss when something is falling behind and say, "We didn't anticipate this. This is the reason it's taking longer".

This is FAR superior to going to the developer and asking them why feature X is taking so long and having them compile a report from Notepad/post-its/white board scribbles. With my process, you can just pull up the project management software and find the tasks that went way over, and the developer stays almost completely insulated from management.

I'm sorry, but you haven't really worked with or had training from real-world engineering managers.

This is the worst kind of condescending ignorance, it betrays an inability for civility that I wouldn't tolerate in a colleague.

Apologies, your perceived "view" of engineers had me fuming. I din't mean to attack you - but I understand where you're coming from.

It is not your fault if your leadership demands detailed answers as to why X is off by Y days. All you're doing is cascading that mistrust/poor management skills to your engineers. I understand what you're doing is the most reliable way to do it, but there is a better way. This is why I mentioned its a people problem.

The better way is to not break down things into hourly tasks but weekly sprints as most teams do. Let your engineers break that down into how much ever granularity they're comfortable with. If something goes off track, build communication trust that helps them keep everyone in the loop and work towards a common goal.

As a product person, I've had the fortune of working in two of the big 4 with some of the best engineers there is - so maybe that contributes to my worldview and it might be terribly biased.

Thanks for explaining :)

Ive developed a habit of doing this very thing, to the point of drafting release schedules to communicate deadlines to management. I love the liberty with my job but you can hang yourself if you don't watch it

I would definitely consider a gulag over this

My current team is estimating up the to one hour and afterwards reporting the work with an hour resolution. It's low cost center squeezing the last cent form the engineering workforce. We are not asked for opinion or for a decision but to implement the tasks distributed by architects and Scrum masters. I'm quitting this place with the first opportunity possible and before taking all holidays until the end of the notice period. I will not even say goodbye.

That's exactly how our corporate IT department works. They get nothing done and working there must be a complete nightmare. I have told my boss that I will refuse to work on anything where they are involved.

"taking all holidays until the end of the notice period"

Do you mean bank holidays? Cause regardless of how you feel about your company, you should always take those. Rest and disconnect from work are important, especially in environments where you really like the work or the job, and the risk of overheating is much greater.

Presumably he means taking his vacation days so he doesn't have to put in any days of work in the 2 weeks after he puts in his notice. I'd guess he isn't American -- the term "holiday" is interchangeable with "vacation" in most of Europe, for instance.

That being said, your point about bank holidays is a good one. Never give your company free labor -- they'll never give you free capital.

I would be careful with this, my last employer refused to pay for unspent vacation days, and if you put in your notice or thought the individual was likely to quit they wouldnt approve your PTO requests. I don't know if this is legal (South Florida), but all the information i find online for this state say that the employer is not required to pay out your time (varies by state).

I mean withdrawing entire remaining annual leave to spend in the office the minimal time possible during the notice period.

I'm pretty sure if you've broken down a larger task to 1-hour pieces, you've already done a large part of the software engineering work. So you've implicitly consumed a considerable amount of (not accounted-for) project time.

My impression has always been that the true cost of a dev task is only revealed when solving it. That's why they're hard to estimate. If they were easy to estimate, they would be trivial to implement and therefore could be largely automated. And for the lack of work, we'd aim for the next larger goal (which is again hard to achieve and estimate).

> If they were easy to estimate, they would be trivial to implement and therefore could be largely automated.

This seems to be a concept so hard to grasp for non technical managers.

By definition tasks aren’t that similar to other tasks, otherwise we would be a super crappy software shop that can’t provide semi-generic solutions.

Dev team’s mission is to solve unique problems to the stack. Discovery is a major time consuming task by definition, and can’t be properly estimated, as it’s an information problem.

This works only if you do things that are well understood beforehand. If you are doing things that require a lot of research and experimentation this project plan falls apart quickly.

Correct. If you have to do research and experimentation before you can make good estimates, then you need to allocate time to do that.

I use the term discovery phase to describe this. You give the discovery phase a certain amount of time to complete, it should be from a few days to 2 weeks. The deliverable at the end of discovery phase is a document. The document explains what experiments were run and what we should do next.

This still rubs me the wrong way. I guess I personally don't like micromanaged environments. I don't want to have to explain every little step and report back all the time to people whose only interest is the deadline. I prefer to be treated like an adult who can be trusted to do the right thing to get to the goal quickly without being supervised at every step.

But I know plenty of people who need constant monitoring and handholding.

I can see GP's point and I don't see it as micromanagement. It's more like intensive investigation. I was "promoted" into management recently and I've had to change my view from "tasks getting done" to "people working together to complete tasks." Getting people to work together fruitfully is pretty difficult and even more difficult when you have a deadline you're shooting for. I don't care as much for reports back to me on progress, but I definitely like to see communication between those doing the task.

This also goes well with the rule mentioned in the article: always have at least 2 people working on a project.

People talking to each other is great. I like to bounce off ideas but I don't like to report to a manager who cares only about time all the time.

It doesn't make things faster but instead takes a lot of mental energy that could be better spent on solving the problem.

This sort of works if you have only a couple discovery tasks. Once you have a few dependent tasks -- that is, C depends on outcome/method of B, which in turn depends on A -- the branching becomes crazy.

Frankly if I'm going to spend a couple days on one aspect, I'd rather just implement that aspect.

I prefer to identify the risky parts and do them first, and refine estimates along the way. TDD helps because it keeps components isolated, so you don't have to build "in order".

Waterfall development with adequate time for planning/discovery up front does for sure give better estimates -- but those estimates are very expensive to get and are usually not all that reliable anyway, especially for multi-month projects.

> If you are doing things that require a lot of research and experimentation

In other words, "anything useful".

> My solution to this has always been to break down the units of work into smaller pieces. Super small. Painfully small.

The problem with this is that the time required to complete all the pieces is almost never equal to the sum of their estimated durations.

I think you are overdoing it simply because per-hour estimates are extremely time consuming to produce and borders on micromanagement.

Realistically, tasks should be grouped into roughly day-sized estimates for any long project with an equally large QA pool possibly run in parallel.

Granularity only gets you so far before the returns diminish to the point of worthlessness. Imho anyway.

I would quit this team.

1 hour tasks! Sound like a recent working environment I was in where I witnessed a poor permanent employee driven to booking 10 mins to a task by this mentality from management down. Also, none of them spoke to each other due to the time-micromanagement. No thanks.

We do a weekly standup with the team (working on the same product) and monthly company all hands. It's very useful to be aware of what everyone is working on. Sure it takes 15 minutes and it's a distraction. Thats why we do it only once a week in person and every day via a Slack channel (simple message, hi i'm working on xyz today). Not doing a standup makes it easier for things to go off track. People working on the wrong things, making mistakes with prioritization by not being aware of what other people are working on. Maybe you don't notice this as much as an individual contributor. As a manager I've seen this go wrong so many times. The group of people should be relatively small. Definitely < 20. But for that group every should have a rough idea of what everyone else is working on.

It's also the realization that I can't/won't fully plan out someone's personal roadmap for them. They need to understand what the team is working on, what the business priorities are and make their own tradeoffs. I set high level priorities of course, but I think people should have control/ownership over their day to day tasks.

I agree. I attend a few meetings whose main purpose is to hear about what's going on with teams whose work is only tangentially related to mine. Sometimes it ends up being useful ("oh, you're stuck on XYZ problem? I think C works on that -- go ask him").

> Providing regular events with alcohol. Peer pressure to drink, bad health habits, bad workplace environment.

> Normalizing and glorifying drinking alcohol.

Sure, alcohol is not healthy, and peer pressure to drink is bad.

But I've found such events to lower some barriers and help connect with people I would usually hardly talk to short of hi and bye. And I think this may affect work productivity as well as personal happiness in a positive way.

The problem with that is, not everyone likes or can have alcohol. If all your events are centered mainly around alcohol, then you're isolating those people from cultures where alcohol use is not common or frowned upon, those people who may have problems with alcohol, and those people who just plain don't want to drink.

I'm not saying never have alcohol at company events, far from it. But don't have every event be centered around it. If you're going to do company events, you need to have a variety of different things, so that, while not every event is everyone's cup of tea, people don't feel isolated at every event, either.

This does seem to be growing into a problem. I have a friend who is a recovering alcoholic and recently he went to a tech meetup where not only was it centered around alcohol but there really wasn't anything else provided. He rightly chided the organizer for not considering that there might be people who want to attend who don't consume alcohol.

I agree with this, it's especially hard in a place like Wisconsin where everywhere is "two bars and a church". I personally drink and don't have any problems with it but I also don't enjoy when every meet-up or company sponsored event is in a bar (not the company I work for but this is a common thing). Have the event at a hotel or establishment with a bar in a separate area if people want to drink. Or have the event and after the main event is concluded say, "As an after event from hours 3 to 6 we'll be doing cocktails at location XYZ if anyone is interested."

I used to have a "no drinking with coworkers" policy, but I loosened that a bit. At smaller, team events I have one drink per hour. At larger company events it's one drink every two hours. In either case it comes out to two drinks per event. But, if I see everyone else getting sloshed at events, I usually step out before things get awkward.

Regular is a very vague term.

After all, "optional one pint of beer after work, once a month" is regular.

"Two or three pints a day, starting at 3pm" is also regular - but sixty times as much.

Loved this. And I agree with most of it.

One thing I disagree with (and I know this puts me in the minority) is code review.

Code review for trusted engineers is a waste of time. You're only going to find those bugs that are very hard to see. And the odds of you catching them in code review are very low. Also, if you're a kind of fast moving startup (like my company is) there's so much new code coming through that it is a serious slowdown to review it all. At least at the level where you'd need to if you're going to catch the things that the original author missed.

I only make juniors and new hires do code reviews. I'll also ask for code reviews if an engineer is taking on a task that's totally new for them. But otherwise we've totally cut them out and been fine.

Eh, half the benefit of code review on teams I've been on is just making the other engineers aware of what's going on. 75% of the code reviews are just a "good to go", the other 20% are questions about why a change was made that inform the other engineers about that particular business constraint, and the last 5% are actual issues.

As you said, it's completely different for junior engineers where it ends up being more like 90% bugs/tech debt, but the code reviews aren't all useless

100% - Most code reviews are. Why are you doing this? please add a comment. Wait! this will break this other thing in some obscure way. Or hey! I built this other thing over here, let's re-use it.

In my opinion the main benefit of code review is diffusion of knowledge. It's kind of pointless to let new hires do reviews.

What knowledge, specifically?

This article describes how the author would deal with or avoid various pitfalls in a business environment.

It's truthful and not "whiney", as the more sociopathic among us are quick to sneer.

However, an underlying thread is needed to weave these criticisms into a meaningful critique. Mismanagement is a theme, but, alone, is insufficient for making the piece persuasive or insightful.

> Writing new systems that don’t need to exist simply to scratch an itch to write (NIH syndrome, etc.)

I've seen this so many times and it almost always ends in failure. Rewrites as well. Engineers can't resist improving a system while rewriting it (adding caching, redundancy, etc). They neglect proving core functionality is intact before making improvements. They also often neglect the thousands of man hours it took to find all the bugs in the system.

I've been building ML systems for a while and I've even seen engineers coming up with their own search/optimization algorithms. This always fails. It's hard enough to get standard techniques to work, since your data usually differs (slightly or severely) from what the technique was validated on (standard, cleaned data sets used for journal papers).

> Someone has a great new design they want to implement which is leagues better than what exists, and the existing design is just so awful. Only, it’s going to require some duct tape here and there, but that’s totally acceptable because overall it’s better. Until it becomes apparent that it’s mostly duct tape, but you’ve gone all-in on this and you can’t go back.

> Solution: Start over. The sunken cost fallacy is real. You’ve made a mistake, and that’s ok, you can take those learnings and build something better. Don’t settle for chaos.

Seems like a smart solution, and yet I almost never hear “throw it out and start over” as an option for dealing with unforeseen problems.

Perhaps as programmers we should take some lessons from writers, who will often throw out all their work from the past day/week/month, because once it goes into production (a published book), you can’t change it. In software, you can change it, yes. But if it doesn’t add anything useful, complicates existing things, or will slow development in the future, there is a clear reason to just drop it and move onto the next approach.

One way to make “just drop it” a more palatable option is to give yourself a grace period from the outset. Something like “if we can’t get this to work in a week, we’ll drop it and reevaluate.” This is when it helps to have at least two people (engineer + manager, or engineer x2) because it eliminates “developer pride” as a variable in decision making and holds someone accountable for making that decision after a week. As a manager, often the most important decisions are not what to build, but what not to build.

Good to see someone took the effort to document the commonly prevalent issues and probable solutions. Doesn't matter how many facts can be arguable or the how much credibility be questionable about the person, finally it boils down to he took the time and effort to document it and share it. Discussion can follow, but there should be something existing to discuss about.

Excellent condensation of the issues. Great ideals to work toward. Just moving in this direction would be helpful in any industry. If we implemented your codebase ideas in education... well, you know we'd have great education.

> Excessive democracy leading to indecision

This is one I've hit a number of times, my solution in the past has been to 'go rogue' and get something done, people will be bothered (usually someone unofficially says it's a good idea), if it works out often enough, we'll start 'deciding' to do more things if for no other reason than to take some credit.

While reading, I was trying to come up with a cohesive idea as to why these things happen, or what single thing could prevent them. The best I could come up with is having a good 'Director of Development' or maybe Project Lead. I don't know what the title should be because I haven't really worked for one. I've worked with great team leads and companies with fine CEOs. CTO's are rarely close enough to the problems being solved and often just not available. I myself worked as a Director of Development for a small startup that eventually ran out of runway. The dev's said they enjoyed working together but I don't think it was long enough or going through the many pivots to test out how that would have been.

Most places I've been have business people that plan projects. Then there are product owners and PMs with teams, design/UX, front-end, back-end, SRE/devops, sometimes even multiple teams with overlapping roles to execute. This I know, doesn't work for long.

Startups that grow and promote internally to fill such a role, may or may not work--depends on the individual. What's really needed is good alignment and balance of business goals and employee happiness. Two things which are both true: startups need to iterate fast to find that magic point; employees are a company's greatest asset. You can't forsake one for the other.

> [0] Please don't comment about the voting on comments. It never does any good, and it makes boring reading.

Despite the quoted item, I couldn't see how to understand the (incorrect?) use of downvoting comments as disagreement rather than to discourage unwanted behaviour which doesn't contribute to a discussion. In any case, a comment as to why is always helpful.

[0] https://news.ycombinator.com/newsguidelines.html

Get a hobby. Relax and don't take work so seriously. I'm not saying avoid responsibilities, but do the best you can and lead by example.

In the UK in the last ten years the average salary for a senior developer has gone up from £35k to nearly £50k but for contractors, weirdly the average rate outside of London has stayed around £350 a day

This post would still hold true if replace the phrase 'tech jobs' with just 'jobs' :) Such a wonderful article on all things wrong at the workplace these days.

I honestly read 2 paragraphs before deciding that a large part of the problem is the author's inability to work through adversity. Maybe even an industry culture of avoiding adversity rather than dealing with it (aka laziness).

Really? I saw a bunch of things that happen when management doesn't want to be held accountable. I saw a bunch of things that end up coming back to the developer to bite them in the ass. I saw a bunch of things that make for long hours and late nights for no valid reason.

Basically, I did see a bunch of adversity, but artificial adversity. Adversity that doesn't make anyone stronger, or better, or even feeling accomplished. Just a bunch of bullshit that one had to wade through. And if you're in the position in your career where you have alternatives, why on earth would you decide to stay in that environment?

Sounds like a really toxic person to work with. Lots of complaints and few solutions.

Be kind.

I agree that my run through of the article seemed to point to problems more than solutions, but I have always felt that the old chestnut 'don't bring me problems, bring me solutions' was a bit shortsighted.

Yes, it would be nice if every problem had a solution provided in a gift wrapped box. Yet, it is dangerous to pretend that problems do not exist simply because we do not know how to solve it.

Now, how to do this without become overwhelmed and despondent in the face of these problems is another issue.

Ive created account only to say "thank you" for writing this article. Thought im just projecting issues that dont really exist because of not so long ride in this bus (just promoted to senior)...

At first i tried to tackle those issues but it seems that nobody cares or doesnt want to accept that we have such issues in the first place. Im just happy others see those issues too and try to solve them at least by rising awerness.

Im also sure that if i tried to bring this article to discussion i would be fired next day because of "playing primadonna" one of our managers use to say...

Almost every bulletpoint has a “Solution:” subheader...

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact