Hacker News Reader

Comment by 6thaccount2 | Hacker News Reader

Is it really common for software engineers to work under these conditions? As an electrical Engineers I have plenty of deadlines and do plenty of work with PMs, but none of this daily standup and thankfully Jira was recently dropped as it was considered more trouble than it is worth (management just wanted to know the big things going on and not all things). Of course it's better than plenty of other jobs, but the constant treatment of employees like they're on an assembly line sounds rough. I know software development is tough and respect those that do it. I have critical time sensitive tasks and I'm expected to have them completed on time. My manager might check in once a month on a year long 1/4 million dollar project among all the other work I do. I know that's peanuts compared to a large software project, but still.

View on HN

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.

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.

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.

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.

That's how it used to be when I started in the 90s. My first projects were pretty much like "Here is the problem. Come back when you have questions" and me and others would often work for weeks without talking to management. Now it seems a lot of companies are doing more micromanagement. I also sometimes wonder if the younger programmers need more handholding these. When I started there were almost no people with formal training in software development so we were all self starters that had learned on our own because that was the only way to get into the field.

The problem is that a client is paying by the hour, so going away for “weeks” to guess and “work” costs literally thousands of dollars. With XP, there would be a problem that would require weeks of obscurity to solve: it would be broken down into a smaller piece. And, you’d be working with your pair on it with frequent interaction with the PM.

I understand that. However I think it’s counterproductive to get daily status updates. It helps with the insecurities of management but I don’t think anything gets down quicker or better . Instead I believe the constant interruptions and second guessing slow things down.

>Is it really common for software engineers to work under these conditions?

It wasn't like this before fads like XP, Agile, Scrum etc. and micro-management became mainstream. Most of the current management done by PMs and their ilk can be easily categorized under "Bullshit Jobs" (https://strikemag.org/bullshit-jobs). The problem is that once somebody has codified their experience under a catchy title and started marketing it, people blindly follow it without understanding its context and applicability. Given that the barrier to entry to these sort of positions are so low (you can become a PM without any sort of domain knowledge!) people who might not cut it as Engineers seek these jobs to boost their pay, power and egos.

PS: The above might come across as a little harsh but unfortunately is the reality for most Engineers.

Agile, XP, insert-other-methadology, is a way to potentially take a developer who is a 2 or 3 and get them working like a 5.

Problem is it also takes the developers who are 8,9 and 10s and turns them into 5s too.

If you have lots of 2s and 3s this is probably fine. If you have more 7s, 8s and 9s it's a problem. For a start the better developers will end up simply leaving as working conditions are too hostile.

Most developers are < 5 / 10 skill wise, so these silly methadologies become stupidly popular.

Software engineers are constantly delivering products to customers. I assume the timeline for an electrical engineering project can be many months or even years, so this isn't very surprising. When you work in an environment using continuous delivery and you are shipping features to customers every day/week, there's no way you can not have more communication. These things have to be documented, support staff trained, project goals tracked, etc.

> As an electrical Engineers I have plenty of deadlines and do plenty of work with PMs, but none of this daily standup

Damn... is it too late to go back to college and study electrical engineering?

Thanks to God it is not. I've only worked for a single company who did this and I left as quick as possible.

Reply on news.ycombinator.com