Expectations of professional software engineers
1–10 of 116 posts
Re: Expectations of professional software engineers
#2It'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
#3Re: Expectations of professional software engineers
#4Interesting cross-over with Mark Burgess's Promise Theory, where a promise serves somewhat as a single discrete expectation.
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…
Re: Expectations of professional software engineers
#6At 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
#7Where is the company that gives engineers enough freedom to satisfy all 50 points?
Re: Expectations of professional software engineers
#8This 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
#9I 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.