Live data from Hacker News

Expectations of professional software engineers

adamj.eu

1–10 of 116 posts

Re: Expectations of professional software engineers

#2
> I can articulate precisely what problem I am trying to solve.

It's appropriate to put this one first because it shows up in so many of the problems that follow.

Easier said than done when there's a deadline pistol pointing at your head. You gotta get stuff done. Show progress. Writing any kind of specification is just a slippery slope to Waterfall, geez. There's no time of any of that namby-pamby talking to and watching users BS. They don't know what they want anyway! Real developers ship!!

Re: Expectations of professional software engineers

#5

> I can articulate precisely what problem I am trying to solve. It's appropriate to put this one first because it shows up in so many of the problems that follow. Easier said than done when there's a deadline pistol pointing at your head. You gotta get stuff done. Show progress. Writing any kind of specification is just a slippery slope to Waterfall, geez. There's no time of any of that namby-pamby talking to and wat…

Excess time pressure is behind so many problems. It's the thing I'm always most concerned to manage when I start a new gig. That said, shipping early and often is one of the best ways to mitigate excess time pressure, because it helps build trust between stakeholders and the team. The longer the release cycle, the more likely it is that business stakeholders will get antsy and start doing harmful things.

Re: Expectations of professional software engineers

#6
> I can articulate why my problem is important to solve.

At this point in the list we start to diverge from what engineers/developers are allowed to know in the modern enterprise. Here is where we start to get push back from the Program/Product managers, Scrum Masters et al. To proceed further down the list is to remove the added communication channels between engineering and the business.

Re: Expectations of professional software engineers

#8
I mean yeah this is great on paper, and applicable for bigger projects, but for day to day stuff there is no way I’m gonna pull another engineer in to run through these steps.

This kinda stuff always reminds me of someone making a PR for something like a react component that lets you choose a time zone. It can be a 100 line simple thing or it can be an 800 line monster with files for typescript types thorough tests, etc. I prefer the former but I feel the author would expect the latter.

Re: Expectations of professional software engineers

#9
I really love these points as a North Star, but these would be mostly aspirational for teams I've been on.

I work on a team now where we get huge scopes of work and a couple people will tear that work down and would answer these questions as they do so. However, most teams I've been on deal with far more interrupts than the team I'm on now does. Those interrupts are lemented but justified by the business and definitely impact an engineers dedication to a given projects. Interrupt driven work is a sort of split brain problem that I think gets in the way of answering these kinds of questions because it removes the time that an engineer would otherwise spend entrenching themselves enough to know the answers and problemscape.

Re: Expectations of professional software engineers

#10
This is a great resource, thank you! Gives me a lot of actionable concrete issues to work on. Maybe I'm just very early in my career or it has to with the subfield I am in (bioinformatics, machine learning) but I should have been fired 20 times over by these standards.
Post reply on HN