
What to do when tech jobs go bad - veidr
https://medium.com/@xevix/what-to-do-when-tech-jobs-go-bad-93e631a1bdc9
======
padobson
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.

~~~
maxxxxx
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.

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

[https://twitter.com/RichRogersIoT/status/864963914483855360](https://twitter.com/RichRogersIoT/status/864963914483855360)

~~~
hinkley
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.

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

------
a_imho
_“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.

~~~
sixdimensional
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.

~~~
s73v3r_
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.

~~~
laythea
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.

~~~
s73v3r_
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.

~~~
Trundle
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.

~~~
s73v3r_
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.

------
rampage101
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.

~~~
chatmasta
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.

~~~
s73v3r_
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!"

~~~
chatmasta
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.

~~~
s73v3r_
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.

~~~
chatmasta
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.

~~~
Nnuie21
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?

------
some_account
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.

~~~
padobson
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.

~~~
ethnicify
This is micromanagement. You're describing micromanagement.

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

~~~
padobson
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.

~~~
alexashka
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.

~~~
dragonwriter
> 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.

~~~
alexashka
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.

------
tschellenbach
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.

~~~
capitalsigma
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").

------
blauditore
> 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.

~~~
s73v3r_
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.

~~~
Zelphyr
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.

~~~
knightofmars
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."

------
methodover
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.

~~~
lovich
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

~~~
nojvek
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.

------
hitekker
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.

------
atridan
> 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).

------
chatmasta
> 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.

------
bprasanna
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.

------
brooklyn_ashey
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.

------
karmakaze
> 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.

~~~
karmakaze
> [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](https://news.ycombinator.com/newsguidelines.html)

------
asow92
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.

------
amriksohata
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

------
rustoo
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.

------
trey-jones
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).

~~~
s73v3r_
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?

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

~~~
old_haus
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.

~~~
the_new_guy_29
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...

