Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Expectations of professional software engineers

adamj.eu

Post reply on HN
Print view View original

81–90 of 116 posts

Re: Expectations of professional software engineers

#81

Post by jeff-davis »

I would add: can explain the level of complexity being introduced and how it will be managed.

More complexity raises the cost to support and develop new features in a non-linear way.

If you do features A, B, and then C; feature C might seem to be the most difficult. But if you do A, C, and then B; feature B might seem to be the most difficult. If you manage complexity poorly in features A, B, and C; then perhaps feature D is too expensive to ever accomplish -- not because it's inherently difficult, but because it's difficult given the complexity already present due to A, B, and C.

To me, this is the fundamental challenge of software engineering. Other kinds of engineers must deal with complexity as well, but it's somewhat more contained due to physical constraints. Software complexity is unrestrained.

Re: Expectations of professional software engineers

#82

Post by systemvoltage »

ctroein89 wrote: post #57

> 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…

> Yikes, that's toxic!

We have a problem where there isn't ever a mild criticism or offering a different perspective. Just because you don't see the world your way, doesn't mean that others are toxic.

I think this is serious problem and should be reflected upon. Sometimes to push your perspective, it starts with considering other perspectives with good intentions. May be people will listen to you.

Re: Expectations of professional software engineers

#83

Post by quickthrower2 »

> I am not actively avoiding any uncomfortable (professional) conversations.

> If there’s something wrong at work, don’t put off talking about it.

> I am not actively avoiding any (professional) conflicts.

> If you’ve noticed something is going wrong, whether technically or communication wise, get those conflicts out in the open. Letting them stew never helps.

This requires a prerequisite of trust which I think is more of a rarity than commonplace. People will speak up about stuff, but not all stuff.

Re: Expectations of professional software engineers

#84

Post by quickthrower2 »

ctroein89 wrote: post #57

> 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…

The problem to be solved can be "I have been given a single sentence specification and I have no idea what the boss wants".

The plan B can be "The boss cannot tell me what they want in a succinct way, and/or I am not confident what they want, so I will make various suggestions and get them to choose an option."

The unknown risks - all developers intuitively should know this unless they are very new. Stuff like "this will work, but not effort is going in to how to scale this up later", or "this requires digging up some old code no one has touched for ages, which could explode the time estimated if it is hard to understand that code or refactor it".

Re: Expectations of professional software engineers

#85

Post by o4b »

perlgeek wrote: post #58
szundi wrote: post #50

This guy lost me when I read that I should implement Plan B first.

I guess that's inspired by the famous "plan to throw one away (because you will, anyway), from Freed Brooks if I remember correctly. IMHO it makes sense if Plan B is much simpler, but not as efficient as Plan A (remember, this is a game developer, everything is about efficiency). You build Plan B is a prototype, and could still fall back on it (and iterate on it) if Plan A fails. If Plan B is more complicated than Pl…

If the point was "write a prototype/less efficient version prior to the more time consuming but better quality solution" then maybe they should have written that.

The connotation with plan B is you do plan A, then if it doesn't work, you do plan B. If you are supposed to implement plan B first then really plan B is plan A.

Re: Expectations of professional software engineers

#86

Post by NikolaNovak »

ctroein89 wrote: post #57

> 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…

I'm not reading those 3 nearly as Cynically.

Number 1 should not be controversial for vast majority of IT. If you cannot articulate what problem you're trying to solve, you won't know when you're done or how to approach it or what it's value is. Anything from scope creep to underfunding to business mis alignment are classical dangers of not having #1. (note it does not read "I know exactly the specific solution and implementation details". Just says "understand what the heck you're trying to accomplish", which I would expand as "understand and agree")

#2 I view tactically and or operationally. It's good, when choosing a tool or approach or algorithm or vendor etc, to know what some alternatives may be. Presumably, you consciously or subconsciously did that work anyway during solutioning or POC or just brainstorming phase.

#3 is basic project management. Articulating risks is crucial. Ideally the developer can do it but if not, for love of all that is unholy, somebody should :). And you should be able to articulate some key unknowns - e. G. I don't know the performance of this yet to be developed application until we get to performance testing.

Re: Expectations of professional software engineers

#87

Post by Aeolun »

eschneider wrote: post #38
mkl95 wrote: post #34

> Say it’s Wednesday, you have a project due on Friday, and you get some new task dropped on your lap. You think “I’ll do the new thing now, and make up the time for the original task by Friday”… mistake! Communicate about the conflict on Wednesday. Your product manager will help manage the timing and risk. My product manager was fired a while ago and no one has replaced him formally yet. A C-level guy is micromanagi…

Assuming (yeah, I know...) new task is 'critical, it's usually enough to go 'We can do that, but it'll push X out. Is that ok?' And if it's not ok, reasonable management will either pick a priority or get you some help to get them both done on time. If you're often getting feedback that you 'need to get them both done by Friday.' you might want to evaluate if your management has their act together.

> If you're often getting feedback that you 'need to get them both done by Friday.'

My response is always that I’ll try, and we’ll see which one ends up half-finished on Friday. This either gets them to pick one, or assume everything will be fine until Friday, when it blows up in their faces.

I don’t think I’ve ever had someone (even the manager) blame it on me for some reason.

Re: Expectations of professional software engineers

#88

Post by Aeolun »

actually_a_dog wrote: post #23
kodah wrote: post #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 definite…

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.

Re: Expectations of professional software engineers

#90

Post by projectazorian »

> 39. I never use the phrase “future proof” when referring to my work. > Future-proofing is “100% a fool’s errand”. “You can’t pre-solve problems you have no information of.”

You can't pre-solve problems you are unaware of but in most software engineering two problems are very predictable:

1. The system will have to handle more load in the future. 2. Someone will eventually want to change the business logic.

It is wise to write software in a way that you are well positioned to resolve those problems as they arise. When I use the word future-proofing in my day to day work, this is what I am referring to.

Post reply on HN