Things they didn’t teach you about software engineering

Post by sideshowb » Sun, Jan 08, 2023, 10:18 AM UTC

atoav wrote: post #31

gregmac wrote: post #14

Earlier quoted context omitted.

I can think of a couple challenges. Let's say you're debugging "the website won't load." Often debugging is a hunch, and quickly branches. One person will go down the path of trying the same site from another PC. Another will try a different site from the same browser/PC. Another will try to ping the server. If you're running this live you're always going to have the chance where someone's hunch or first try basicall…

Sure testing a beginner is hard here. But testing someone who learned how to debug means testing their knowledge of the moving parts of the system they are debugging. And this can be explained by the person being tested. E.g. "I am going to ping an IP on the outside first, to see if ICMP message reaches the outside server. If yes I will check if the DNS server responds, if no we check the physical connection." That w…

Post by josephg » Sun, Jan 08, 2023, 1:33 PM UTC

gregmac wrote: post #208

josephg wrote: post #56

Earlier quoted context omitted.

It can. I love using debugging problems as an interview question. Give the candidate some simple code (~200-300 lines is probably about right) with a handful of failing unit tests. Sit them down, walk them through running the test suite and ask them to find and fix as many bugs as they can in 30 minutes. It pays to make the first bug trivial (like, a typo or something) and make the subsequent bugs increasingly subtle…

Debugging works extremely well during an interview because: 1. Your evaluation can be interactive: you're watching them step through, can stop and ask questions about their thought process, etc. If it's a theoretical problem (ie: not on a live computer) you can even re-calibrate on-the-fly if they're really quick (maybe a lucky guess) at narrowing down the issue, or just asking "what if this happened instead, what wo…

Post by mfuzzey » Sun, Jan 08, 2023, 5:14 PM UTC

rco8786 wrote: post #148

galangalalgol wrote: post #142

Earlier quoted context omitted.

I had a boss for a while that took the opposite view. He just wanted to do interesting work. He was good at politics so he did, but the level he would have risen to in management if he had focused on business goals and money instead of fun work would have been much greater. But he also wouldn't have still been doing daily technical work which is all he wanted. We acknowledge that fun work can be part of total compens…

Yea no issues with that at all. That's why I prefaced my entire comment with "If you want to stand out in your career".

Post by pjmlp » Sun, Jan 08, 2023, 10:12 PM UTC

Post by rco8786 » Sun, Jan 08, 2023, 10:41 PM UTC

yobbo wrote: post #272

rco8786 wrote: post #138

Pretty decent article (don't agree with everything, but for the most part) > Code is secondary. Business value is first. I wish I could shout this from a mountaintop. If there's one thing I could change about engineering culture it would be this. But then again I would lose my edge if everyone understood this, so maybe it's best that they don't Engineers: If you want to stand out in your career - take this to heart.…

> Money is the goal, code is a tool to get the money. This is an obvious and empty statement if it's not used in specific cases. Unless you have something new to add in the "how to get money debate" the distinction between "code" and "value" is irrelevant. When I've heard this, it's typically way to trivialise engineers and shut down discussion. " I don't understand how this contributes value, therefore all your cont…