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

61–70 of 116 posts

Re: Expectations of professional software engineers

#61

Post by outworlder »

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…

And that's precisely why 'spikes' or 'POCs' exist. It's way more common to not have all the answers if you are working on anything remotely interesting. There should be some time to explore solutions. In even more interesting cases, solving the unknowns is the entire project.

It seems that the author has never encountered the "research" side of R&D.

Re: Expectations of professional software engineers

#62

Post by gnuvince »

feoren wrote: post #31
mjw1007 wrote: post #22

His expectations around producing documentation go only as far as "Think about what documentation or data users need to understand and use your solution." That seems like rather a low bar, compared to items like "I can articulate how all the data I use is laid out in memory." I'd prefer to live in a world where a professional software engineer was expected to write documentation, and expected to be competent at it.

> I can articulate how all the data I use is laid out in memory. That's not a high bar, it's an arbitrary hoop. It'd be like saying "I always know which processor cache my variables are sitting in". In modern languages it may be literally impossible to look at a block of code and know what's sitting in the heap vs. on the stack, and the heap is often broken into many different components only fully understood by the…

> We want to abdicate responsibility of this kind of memory management to the interpreter, just like we want to abdicate responsibility for handling processor cache levels. If you can articulate how all the data you use is laid out in memory all the time, you are majorly micro-managing the runtime.

Unfortunately, in practice, it's not possible to be oblivious of the layout of data in memory if we want to write fast code. The CPU/memory speed disparity graph [1] shows the new reality for programmers: the slowest part of a program is bringing data from RAM into the CPU registers. Fortunately, modern CPUs have very fast caches that help amortize this cost and it's the responsibility of the programmer to organize data to take advantage of that fast hardware—the compiler cannot do it. That's why two functions, with the same algorithmic complexity, and which compute the same result, can have an order of magnitude of difference in performance between them [2]. The famed sufficiently smart compiler that can do those transformations does not yet exist as far as I know.

[1] https://gameprogrammingpatterns.com/images/data-locality-cha... [2] https://play.rust-lang.org/?version=stable&mode=release&edit...

Re: Expectations of professional software engineers

#63

Post by MajimasEyepatch »

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…

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 you sit down to work on something and realize you can’t articulate the problem, the first step is to stop and focus on defining the problem better.

Point 1 is a prerequisite to points 6 and 9. But once you’re ready to start actually building a solution, you should absolutely have an understanding of the risks and a Plan B in case your solution fails.

Nowhere in the article does it imply that you can fully understand a problem without putting in the work. The difference between juniors and seniors that the article is highlighting is that juniors will jump into implementation without knowing these things, while seniors will take time to do some research and figure these things out first. Usually, if you’re senior, you should also have the experience to do so quickly, but that’s not always possible.

Re: Expectations of professional software engineers

#64

Post by nooorofe »

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…

Term "toxic" is toxic by itself.

Periods when engineer don't understand the problem should be spent on analysis of the problem domain. "Now I am working on defining the problem domain" - is an activity to work "I don't understand the problem" task. During that period probably zero code will be written.

> That author only encounters problems that have been fully solved before

He doesn't, otherwise there would be no talk about "plan B" and risks. When you actively write a project code, you should know that solution is possible. Having plan doesn't mean "problems have been fully solved before". You may have POC which doesn't end in resolution, but it should be clear what is POC for and a failure is possible outcome.

Re: Expectations of professional software engineers

#65

Post by perrygeo »

horsawlarway wrote: post #12

Personally - I don't see a lot of value in this list (I read all 50 items and watched the video and I regret wasting the time). There are certainly some valuable concepts - but the presentation is fairly incoherent (including the video of the talk he gives) and not particularly helpful. Many of these items are utterly unrelated: Some are fairly specific to gaming (profiling/memory layout/timing) some are basic profes…

I found some value in this list (read it, but didn't watch) but I agree that 50 unorganized bullet points is too much. I think they could break it down into 6 or 7 larger themes: communication, being a good citizen, using a systematic development process, investing in developer tools, understanding real world end-user requirements, technical requirements, and data flows. All good advice, maybe not the best delivery.

Re: Expectations of professional software engineers

#66

Post by MajimasEyepatch »

outworlder wrote: post #61
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…

And that's precisely why 'spikes' or 'POCs' exist. It's way more common to not have all the answers if you are working on anything remotely interesting. There should be some time to explore solutions. In even more interesting cases, solving the unknowns is the entire project. It seems that the author has never encountered the "research" side of R&D.

Where does the article imply that seniors don’t do research? How exactly do you expect that anyone can know these things without doing research? The point of the article is that juniors jump into the work without doing the research to figure these things out, while seniors take the time to figure these things out. Sure, maybe they can do that quickly based on experience, but I don’t think the article implies that seniors don’t do research.

Re: Expectations of professional software engineers

#67

Post by datagram »

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 don't think the rules imply any of that.

"No one has ever solved this problem before and I'm not sure where to start" seems like an important unknown/risk to let your manager/lead know about. Likewise, the backup plan can just be "we scrap that feature" or "we solve a much simpler problem". The point is to be deliberate about what you're doing and communicate potential setbacks.

Re: Expectations of professional software engineers

#68

Post by MajimasEyepatch »

vsareto wrote: post #21
nottorp wrote: post #7

How much would they pay for someone who satisfies all 50 points? Where is the company that gives engineers enough freedom to satisfy all 50 points?

This list will impede velocity by quite a lot, especially with coming up with and implementing Plan B's

You only implement the Plan B if Plan A fails. Plan B doesn’t have to be elaborate. It can be as simple as, “I’m going to look into using this third-party service to solve 99% of this problem, but if it isn’t a good fit or it’s too expensive, I think we can put together a home-grown 80% solution in a couple of sprints.”

Re: Expectations of professional software engineers

#69

Post by fjfbsufhdvfy »

mjw1007 wrote: post #22

His expectations around producing documentation go only as far as "Think about what documentation or data users need to understand and use your solution." That seems like rather a low bar, compared to items like "I can articulate how all the data I use is laid out in memory." I'd prefer to live in a world where a professional software engineer was expected to write documentation, and expected to be competent at it.

Knowing how your data is structured in memory is a trivial exercise for anyone working on a game engine like the author of this talk. You don't even need to think about it. The layout of every data structure used by the engine is known and chances are you have implemented a bunch of them yourself.

Re: Expectations of professional software engineers

#70

Post by ChrisMarshallNY »

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…

> figuring out the problem is part of the work

IME, finding the problem is almost all of the work.

Once I can reproduce an issue, and trace it to its genesis, it's as good as solved.

Post reply on HN