Comment by finder83 | Hacker News Reader

Comment by finder83 | Hacker News Reader

Parent Full thread

It depends a lot on the company. I've been fortunate enough to avoid companies like the one posted, but there really are two (maybe three) views of developers:

1.) Treat them as engineers who are capable, able to communicate problems or expected delays, and professionals who want to grow. 2.) Treat them as assembly line workers who constantly want to screw around and need to be whipped back into shape.

I'd argue maybe a third is the startup mentality where you need to sell your life to the company, but maybe that's a mutually exclusive thing.

In my experience, the second comes from the same mentality as the old waterfall companies. Spec everything, trust no developer, micromanage, etc. Developers are a risk, not an asset, and never trust them at a management level. I would never work for a company like that, and avoid them like the plague.

Regardless, both of the views above seem to be a self fulfilling prophecy. Professional shops who treat developers as engineers produce some quality stuff and usually on time. Sweat shops have a lot of failed and over-budget projects and a high turnover.

In my experience "the old waterfall companies" are the ones where the engineers are trusted with a task and left to do their thing. In such an environment, managers are only there to assist the engineers. I.e. escalate issues, provide ressources etc. and most importantly: fight for their team/department in meetings. We go to our team lead only when it is necessary and he only asks for updates when he needs to report our status to a superior.

What I have witnessed in those hip, agile young companies is that you have to report exactly what yyou have done, what you are plannign to do etc. constantly. At least once a day, plus whatever other weekly meetings you are in. Sometimes your entire day is filled with meetings and you are supposed to fit your actual work somewhere in the breaks. And if you can't finish a task in a day, you trigger extra attention from managers and suddenly you find yourself sitting at your desk with another engineer and a manager looking over your shoulder, wasting hours of expensive time instead of letting you work.

Those are the two extremes I have encountered and they are only annecdotes. But they do serve to show that the development process chosen for a project is not tell you anything about the management style.

Interesting. What I meant by "old waterfall companies" is that there's a few businesses in town that write enterprise software, oracle, etc, for fortune 500s. Those tend to not be kind to their developers, and have been around for a while.

I have worked for another large telecom that treated its developers great that did kanban.

Currently I work for an agency that really does neither. :-D

But I think you're right, the methodology doesn't matter nearly as much as the managers.

What's odd about the "agile" companies, is that while you are a designer or engineer in product mode, you're not supposed to attend any meetings beyond daily standup, weekly IPM, and weekly retro... Maybe the odd town hall. Maybe the odd inception day or cross-team retro every few months for a major new initiative. But that's about it. PMs do attend other meetings mostly as a liaison to the outside world, because that's the gig, but even then, it tends to be limited.

The whole point (at least at Pivotal) is to spend more time coding/designing/testing and not in meetings.

Thanks for the insight. I like programming and read and write plenty of code, but it is a part of my job (tool in the belt) and not the focus. In my opinion, there are always so many unknowns for any project that scoping something out entirely beforehand seems entirely useless. I'd much rather sketch some diagrams on paper and try to implement something that works but is a little ugly and then make a second pass to clean it up and properly architect it. I can't do that to start without a better understanding of the problem. I suppose if you write a lot of the same kinds of software you can estimate up front pretty accurately though.

> I'd much rather sketch some diagrams on paper and try to implement something that works but is a little ugly and then make a second pass to clean it up and properly architect it.

Fred Brooks said "plan to throw one away, you will anyhow". He was mostly talking about the value of prototyping or what in some circles is called spiking.

> I suppose if you write a lot of the same kinds of software you can estimate up front pretty accurately though.

Not in my experience, and I'm a pro-estimate loony. A lot of products and problems do have fairly predictable elements and it's possible to give useful estimates (eg, add new form element, needs a new field in the endpoint, new column on the table, some validations, tests for the above, no changes to docs ...).

Other problems are closer to pure research and you just accept someone might come back with something some day.

What we argue about in software circles is how wide valley in the middle is.

> it's possible to give useful estimates

I think an engineer needs freedom to be able to exercise judgement say "I don't understand this task well enough to estimate it yet."

Why? Speaking from personal experience, when I was a recent grad and got asked for an estimate, said "I don't know" and then got pressed for one, my thought process was "okay... I guess I'll just come up with a number and double it" because thats the advice I'd been given multiple times. This resulted in an estimate that had no relationship with reality and which I knew had no relationship with reality. This was not helpful for communication because...well because it was a lie. Thats the key: unless you give someone the freedom to say "I cannot yet give you an estimate", you can't know if the estimate you get is a lie.

Establishing this freedom is hard:

* One reason that it can be hard to give estimates of simple tasks like adding a new form element/adding a new field in an endpoint/adding a new column on a table is if you don't yet know your tools well. But it can be rather embarrassing to admit this. So the engineer can be reluctant to exercise the backbone to claim this freedom.

* There is a lot of moralizing around estimates. The article On Being a Senior Engineer[1] says "Avoiding responsibility for estimates is another way of saying, 'I’m not ready to be relied upon for building critical pieces of infrastructure.'" so admitting that you don't yet know how to estimate might be admitting that you should be fired.

* This is hopefully an uncommon case, but an engineer might have been unwittingly hired as a senior engineer right out of university because their recruiter told the business he'd known the engineer for years. This exacerbates the previous point.

* A business stakeholder really wants to have an estimate, even if the reality of the world is that engineer can't give them one.

* There aren't any resources for new engineers to learn task-estimation[2]. So if one of your engineers doesn't know how to estimate tasks, you might worry that they'll never learn how, since coaching that engineer to learn estimation is too time-intensive an option for most companies.

* When an engineer is asked "how long will this take?", it isn't obvious from that question that the estimation process requires first identifying the key pieces of the task and the riskiest pieces of this. That relies on knowledge of how to produce estimates: understanding that they key piece of estimation is not the number you get at the end but is the mile-markers you produce along the way.

All of these difficulties hurt the key thing required for a good conversation around estimates: trust. Trust that the person hearing the estimate knows that there is uncertainty. Trust that the engineer will flag up if they run into a pile of complexity.

[1] https://www.kitchensoap.com/2012/10/25/on-being-a-senior-eng...

[2] Demystifying the Black Art by Steve McConnell is about project estimation, which assumes you can already estimate individual tasks.

> I think an engineer needs freedom to be able to exercise judgement say "I don't understand this task well enough to estimate it yet."

Absolutely. This is itself a valuable estimate. Very occasionally engineers will give a very high points value to indicate that the proposed story is simply too complex as written and needs to be decomposed further.

> Establishing this freedom is hard:

It absolutely is. Everything we do at Pivotal that works well is actually hard. Our cheat code for bootstrapping these practices is that we already bootstrapped them years ago. But maintaining a culture is harder than building one, which is a trillion times harder than improving one.

Reply on news.ycombinator.com