Live data from Hacker News

Expectations of professional software engineers

adamj.eu

111–116 of 116 posts

Re: Expectations of professional software engineers

#111

> 1. I can articulate precisely what problem I am trying to solve. > 6. I have a Plan B in case my solution to my current problem doesn’t work. > 9. I can clearly articulate unknowns and risks associated with my current problem. These rules imply one of 3 things about the author: * That author only encounters problems that have been fully solved before * The manager gives zero weight or value to discovery * The manag…

This is a strange interpretation. It does not matter whether you are working on the simplest web page or a brand new problem that no one has solved before: it is absolutely necessary that you clearly articulate the problem you are trying to solve. Even if you’re a scientist working in a purely exploratory, theoretical setting, you still have to be able to articulate your problem. You may refine that as you go, but if…

Quoting a researcher: "If you knew what you were doing, it would not be research." (Daniel Lemire, while talking about research grant proposals.)

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

You can read this in multiple ways, but I'm reading it as: "I'm not participating in the process of figuring out which problems we can solve. I will only ask for clarification of your intent, never try something on my own."

Re: Expectations of professional software engineers

#112

Earlier quoted context omitted.

This is a strange interpretation. It does not matter whether you are working on the simplest web page or a brand new problem that no one has solved before: it is absolutely necessary that you clearly articulate the problem you are trying to solve. Even if you’re a scientist working in a purely exploratory, theoretical setting, you still have to be able to articulate your problem. You may refine that as you go, but if…

It’s reasonable to have tickets that are “is this API interesting to us?” or “how do clients use this new system?” It’s not a “problem”, and there aren’t definite goals. The task is open-ended, and it’s ultimately up to the developer’s judgement to decide that they are done. To define terms, “the problem” is the issue faced by the client or the customer. The task isn’t the problem. A team should tackle tens or hundre…

I think you're using a different definition of 'problem'. Maybe a better word is 'goal'. The point is: you have to know why you are doing something.

Re: Expectations of professional software engineers

#113
post #106

Earlier quoted context omitted.

Most of the points seem to be 'Do I have situational awareness of how what I'm doing fits into the bigger picture.' Generally a good thing to have.

Not just that, but also "am I in the habit of doing things that are conducive to situational awareness" which is perhaps the even more important bit! You can have all the situational awareness in the world now, but when it really matters is when the context changes.

No disagreement, but I'd suggest that situational awareness is an ongoing thing, so if you don't notice when context changes, you never really had situational awareness.

Re: Expectations of professional software engineers

#114

Earlier quoted context omitted.

If he's arguing with his boss in the shower, that may indicate he's a bad communicator.

If he’s arguing with his boss in the shower he’s probably going to be fired for inappropriate behaviour.

Or one of them is just bad at managing expectations.

Re: Expectations of professional software engineers

#115
post #106

Earlier quoted context omitted.

Not just that, but also "am I in the habit of doing things that are conducive to situational awareness" which is perhaps the even more important bit! You can have all the situational awareness in the world now, but when it really matters is when the context changes.

No disagreement, but I'd suggest that situational awareness is an ongoing thing, so if you don't notice when context changes, you never really had situational awareness.

One funny thing about situational awareness is that when you lose it, you don't always know, because, well, you've lost your SA.

Put differently, something you consistently find when you postmortem incidents where people have lost their SA is that they thought at the time they had full SA. They only notice they've lost it when things are clearly going downhill.

So it's important to regularly re-ground yourself with reality even if you think you don't need it. That's a critical component of maintaining SA.

Re: Expectations of professional software engineers

#116
post #88

Earlier quoted context omitted.

It sounds like you don't think these expectations are unreasonable in a healthy environment. Is that what you're getting at? I believe it's possible to hit 50/50, and I think I personally do (with the caveat that I don't do all of these things explicitly, every time, on every project), BUT I'm also on a high performing team in a healthy work environment.

> I believe it's possible to hit 50/50 I don’t believe this is possible in an average company. If these were actually the bar, everyone in our company (including me) would get fired, and nobody would ever get hired again.

You're conflating "possible" with "the bar" here. That's not at all what I said.
Post reply on HN