Hacker News Reader

I've noticed that there are some managers that want their underlings to be just "meat robots" that do as they told without question. Other managers value independent thinkers that can be given an abstract task and find a solution, even if that solution ends up being very different to what was originally envisaged.

The strange thing is that both approaches can be successful!

However, they are not compatible. At most, it's possible to have an out-of-the-box thinker above a team of robots, but that's about the maximum extent of mixing that works.

For example, in the robot-based team, managers generally don't explain any of the inputs and constraints that went into a decision to their underlings. This saves time, allowing them to manage more people to get more done. However, the creative types question everything, which irritates and frustrates them. In an all-creative team, managers will explain the backstory to the junior staff, giving them the information they require to seek alternative but compatible solutions. This takes longer, but then they can offload a lot of the decision making to the juniors.

Don't feel bad that you didn't fit in, it just means that you need to find a place with a corporate culture that suits you better.

You're right, both approaches are important, but sometimes the task at hand requires one or the other - bot not both.

For example, when there is an abstract or undefined problem to be solved, the 'free thinking' people are super valuable because they can search for hidden requirements, think about edge cases and most importantly, challenge established ideas to come about with a better solution.

On the other hand, sometimes the solution is clearly known and you just need to grind it out. Think about the code that you've written over and over again (for us it is market data feed handlers) and there's nothing novel about it. Just gotta get the work done. I've seen some people try to reinvent the wheel for these tasks and its just not needed.

We had this joke at one company where we'd say "are you rewriting rsync?" because every once in a while someone would try to do something brand new and shiny when the tech was already defined and the parts needed to be assembled. Conversely, we also had some folks who did things that were incredibly creative and fresh. It's all about balance.

I like how you didn't say "x is bad"

Though I feel that delegating decision-making scales way better

In my own experience (and opinion), your style of development often results in better quality code, less bugs, and cleaner UX. The tradeoff, as you experienced, is time.

I can also tell you that maximum code quality is not always the priority. This is especially true in games, where you ship and then move onto the next project. Even online games nowadays often shut down after not long, and so they don't need quite as much maintenance as a successful SAAS.

Again in my experience, the super-pro devs I know are particularly good at knowing when to be fast and reckless, and when to be slow and calculating.

My boss once told me ..

When they say 'Good, Fast, Cheap: pick 2', everybody always assumes the point is you have to pick Good and the choice is just between Fast and Cheap.

But Fast and Cheap has its place, ask any game developer ...

Thats because "Good" is a subjective ideal, and one that can be applied to different axes.

Good for game-development might be "a good game", not "good code", for example.

(I know you likely know this, but it's an interesting discussion point I think!)

The result of this "we don't need quality" line of thinking is that almost every AAA game release nowadays is a gigantic fiasco. Nobody wants actually to buy alpha quality shit any more!

I guess games could have much higher sales (especially when the thing is new and hot) if they wouldn't release utter garbage for the most time. Just go and ask people whether they're keen on buying a bunch of bugs for 60 to 80 bucks. Most people aren't. Only a very small group of die hard fans does this.

The whole indie scene wouldn't stand a chance likely if the big players were able to deliver stuff that works actually before the first couple of patches. It's a kind of joke that one or a few people can build much better games than multi-billion companies. The problem is the mindset at the later!

I'm not advocating for "maximum code quality" as you don't get that anywhere anyway for any reasonable price. But game releases are just far beyond any pain point. The usual advice is: Don't touch, don't buy, until they proved that they're willing to fix their mess!

The games industry would need to walk a really long distance before they could get rid again of this public perception. But they need to start somewhere. Otherwise their reputation will reach absolute zero real soon now. They're already almost there…

> games could have much higher sales

Problem is, execs would like 300M revenue now, with a buggy PoS, than 500M after 6-12 months. Because those 300M can let them make another crappy game and release it 6 months earlier (12 if both skip on quality). Then you are missing 400M revenue, but you get 600M 12 months earlier. That recoups costs and looks nicer on reports.

Or in other words, gamers hate buggy releases, but not enough to change the practice.

> Nobody wants actually to buy alpha quality shit any more!

Sadly, I do not think that is true. Plenty of those games continue to sell in huge numbers.

> The tradeoff, as you experienced, is time.

This is true, but it's not the tradeoff most people think. It's not "this way is better but takes more time", it's "spend time now vs. spend time later."

In my experience, you will always spend the time. Spending it earlier can be difficult when you're on a tight schedule which is driving the process, but you'll always spend at least as much time later.

You only spend the time later if you're still working on that project later. It could have failed, done it's job, or you could have moved on to the next project leaving some other poor schmuck to spend the time later.

> In my experience, you will always spend the time.

not in mine, but I've seen a fair amount of very one-off, time-limited projects (the shortest being a client calling a morning for a very simple customized video playback app needed for that very evening, and a lot of it being only needed for a few months)

True, that’s an exception. It reminds me of the way some missile control software never bothers to free memory because by the time it runs out of RAM it’s already exploded…

You most likely ran into a bad lead. His/her role was to coach & mentor you to help you become a better engineer, not just to draw diagrams on a white board.

"everyone knew how to make software" -> if that was the case, you should have found help and support around you organically.

I hope you're in a better situation now. Don't let this kind of experience hurt your self-esteem. You deserved a better place.

The straight line from point a -> b can only be drawn backwards, i.e. from hindsight. When you zoom out, we all goes in circle/iteration. It is true that in some domains some engineers might have better insight than their users, but not all domains. It is important to keep the humility or be conscious that there exist an unknown world to us.

If your former team lead went from a -> b with no problem, maybe he is part of the circle. Afterall, when you zoom in the circle close enough, it appears a straight line. Or he could be a visionary, I can't tell.

An organization is like a shark, it needs to move forward. That organization can be an one-man team, where thinking overlaps with doing. In larger org, specialization is inevitable. The "no question ask, get things done" way that your former team lead adopted is desirable to certain degree, some of the time. But it is important to be aware of the duality. "Disagree but commit" is a virtue.

A fish can teach you swim, but it probably doesn't know it is in water

There are tasks you are experienced with that you can pretty much jump on and just do them, but there's also the other 90%.

What's weirdest about your story is that you were laid off a few weeks into your job. People usually get more time to get the hang of it even if they are senior, so I would mostly assume that it was a cultural fit rather than performance.

Some outsourcing/service (billed by the hour — which explains it for the most part) companies would look for very strict delivery cadence with focus on exactly the process you describe, but you'd be unlikely to have contact with the user in that case (just the customer).

Most importantly, if you ever get fired, be sure to ask for the explanation so you don't end up being baffled.

To clarify I was laid off few weeks after the feedback. I was on the job for a few months.

I asked for the reason, and it was indeed the performance.

It was just the diagrams in the original article that reminded me of this. It just didn't make any sense to me that one would "just solve" a problem at hand without considering other options.

But in my (15 years of) experience the "pi factor" is indeed quite accurate as there is always something surprising that comes up along the way, be it specification changes or technical issues.

To me, 3x is not "accurate" at all: it might be the approximate average, but I've worked on tasks that take anywhere from 0.1x to 10x the original estimate (or rather, a guess). Some were even infinite, in that they were scrapped when the real cost was uncovered.

That's true, the 3.14 is a good average to start with

This is a great question! When I was a developer I used to develop software the way you were told not to. I did it that way because the requirements were always very vague and a lot of gaps needed to be filled. But when I was a project manager I thought that way of development is wasteful and would rather developers didn't do what I did.

So I suppose the real answer depends on the environment you're in. If the project is meant to be agile then you probably need a bit of interaction with the user to get the job done. If the project is not agile and all the requirements could be known up-front then you're probably wasting effort having programmers determine what those requirements are. IMHO.

I worked at an "agency" that could be described exactly like that, though they were not as successful and additionally have a bad reputation amongst recruiters and the local tech scene as a result of the gaslighting, unreasonable expectations, and deliberately moving goal posts in order to fluster people and have "reason" to fire them.

It seems that these toxic environments thrive when the top level of the management encourages this behaviour.

I've heard game development is pretty ruthless.

You showed them you're paying attention. That usually scares the crap out of people who have something to hide. The lesson here is that you were working in a den of vipers, and you're better off elsewhere.

I've met similar thinking. In one company I was working for some time in a senior role, while being new there, I got scoffed for asking the non-senior developers of the team for information on some parts of how the software worked.

Maybe you went over somebodys head, or maybe rank played a part in this. Some people also want you to follor their way or the highway, unfortunately I've seen this many times in different software companies.

Probably in this kind of teams execution is what matters, not thinking for yourself.

I work in Google and it's nothing like this (as long as by "the users" you mean the two-four teams you interface with, not the one-two billion humans using the end product). Your approach to problems would fit right in and the described manager wouldn't keep managing for long.

On the other hand, I once mentored a person working in another company. I've been giving advice that I would give to a junior Googler. They got fired :(

Nope, this ticks for me all signs of a bad/incompetent team lead. I’ve seen lots of teams in my career. I certainly wouldn’t promote or hire someone for team lead if answered the question like this guy about what makes a good software developer. This is a sign for management by metrics which works short-term but ultimately leads to demise of the product.