Things they didn’t teach you about software engineering • Hacker News Board

Re: Things they didn’t teach you about software engineering

#151

Post by LtWorf » Sat, Jan 07, 2023, 1:18 PM UTC

fatneckbeard wrote: post #140

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 not the goal. providing a useful and valuable product or service to customers is the goal.

The successful startups hardly ever do that.

Re: Things they didn’t teach you about software engineering

#152

Post by mypastself » Sat, Jan 07, 2023, 1:21 PM UTC

Some good points here. But I also have to make some objections.

> You’ll need to work around incompetence

It’s amusing that the article never suggests you might be incompetent. No, no, it’s the “other person” whose incompetence needs to be well-documented.

> Rare work-life balance. In other professions, your work day ends at 18:00, and you forget about the job. Not here. You will most likely always be online and checking the code, even in the evening.

I’ve always tended to avoid this throughout my career, and my bosses and coworkers have always been made aware of that.

Wait. Would I be the incompetent the author is talking about?

Re: Things they didn’t teach you about software engineering

#153

Post by no1lives4ever » Sat, Jan 07, 2023, 1:21 PM UTC

orderedtree wrote: post #7

invalidname wrote: post #3

I like this list. It's also missing "debugging". That's a skill that they don't emphasize in college because they can't test it and it's hard to teach. But there are ways to teach it and techniques. There are some books on the subject: https://www.amazon.com/dp/1484290410/ https://www.whyprogramsfail.com/ That can mitigate that a bit.

Why can't debugging be tested?

One of the problems with debugging is that everyone seems to approach it differently. With some of the approaches working better than others in some situations. Which is why a group debugging session works great when you have a tricky problem that is not getting solved by one person.

We can definitely test for basic debugging and troubleshooting skills. But I havent found a way to consistently evaluate people who are capable of identifying and finding solutions to complex problems. These days a lot of these come down to framework level experience. With the proliferation of frameworks and tools used in modern apps, it is impossible to find someone who can solve problems involving all of them. So in a big team you want a variety of such experiences to cover a wider base.

Having said that, I have been in many situations where i have had to join a debugging session involving technologies or programming languages where i have had zero prior knowledge and have moved things towards a solution by asking what at times seems like basic queries to help others come up with the solution.

Re: Things they didn’t teach you about software engineering

#154

Post by no1lives4ever » Sat, Jan 07, 2023, 1:23 PM 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…

And what if the firewall blocks icmp? What if the dns server is internal to the network and is returning a stale ip? There are way too paths down this rabbit hole.

Re: Things they didn’t teach you about software engineering

#155

Post by no1lives4ever » Sat, Jan 07, 2023, 1:26 PM UTC

clintonb wrote: post #19

orderedtree wrote: post #7

Earlier quoted context omitted.

Why can't debugging be tested?

Debugging is difficult to test in a university/exam setting, but can be tested in an observational sense. Stripe does it in one of the on-site interviews.

I have been in enough debugging sessions to know that it is easy to weed out those who are bad from those who have the basics right. But trying to know if a candidate is good with advanced debugging is a futile exercise. You need to be in a few intense sessions with such people to know who are good/bad at these things.

I have only been able to figure this about people after working with them for 6-12 months. Which is why it helps keep references to such people and have them on your teams in future ;-)

Re: Things they didn’t teach you about software engineering

#156

Post by marginalia_nu » Sat, Jan 07, 2023, 1:28 PM UTC

clintonb wrote: post #19

orderedtree wrote: post #7

Earlier quoted context omitted.

Why can't debugging be tested?

Debugging is difficult to test in a university/exam setting, but can be tested in an observational sense. Stripe does it in one of the on-site interviews.

A compounding factor is that it's much harder to debug code you're not at least reasonably familiar with.

Even if you can gain such intuition through looking at a piece of code, in a realistic scenario, more often than not you don't actually know in which file or method the bug is hiding. What you have is a code base and some externality that is wrong, the debugging process is essentially deepening your understanding of the relevant code (in relationship to what it should be doing) until you understand what is wrong.

Debugging isn't being able to use a debugger or a profiler or syscall tracing tool or whatever, sure they help but the critical skill is being able to quickly and accurately model the behavior of a system in your head, in combination with a tacit understanding of where bugs tend to occur.

Re: Things they didn’t teach you about software engineering

#157

Post by xyzzy4747 » Sat, Jan 07, 2023, 1:31 PM UTC

fatneckbeard wrote: post #140

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 not the goal. providing a useful and valuable product or service to customers is the goal.

This is incorrect. Without money you won't get salaries. And people will need to find another job (at a place that does value money).

Re: Things they didn’t teach you about software engineering

#158

Post by watwut » Sat, Jan 07, 2023, 1:34 PM UTC

Galanwe wrote: post #39

quanticle wrote: post #27

Rare work-life balance. In other professions, your work day ends at 18:00, and you forget about the job. Not here. You will most likely always be online and checking the code, even in the evening. If that's the case, quit immediately. I've been in this industry for over a decade (oh god, has it been that long already?) and I have never had a job where I was "always online and checking the code, even in the evening".…

> If that's the case, quit immediately If you're so uninterested by your work that thinking about it after 6pm makes you sick, why did you pick it? I've been in the industry for 15 years, coding since 25+ years, and I very often think, code, read about work or work related things at any time of the day or weekend or vacation, because I find it interesting. Why would I work in something of no interest to me?

Because you are building strawman and false dichotomy. And also because people able to take proper rest are more productive in the long term.

Re: Things they didn’t teach you about software engineering

#159

Post by alpaca128 » Sat, Jan 07, 2023, 1:35 PM UTC

Galanwe wrote: post #66

r_hoods_ghost wrote: post #61

Earlier quoted context omitted.

Because there is a very strong negative correlation between overworking and productivity / quality of work. When I've been line managing people I find that if they work over 40-45 hours a week their actual productivity (as opposed to their self perceived productivity) starts to fall off a cliff after a couple of weeks, so I ask people to only work their hours. I've sometimes had to implement technical measures to enf…

> Because there is a very strong negative correlation between overworking and productivity / quality of work Working outside of business hours is not the same as overworking. I have some days packed with meetings and calls, and I actually find it refreshing/relaxing to work on more down to earth matters in the evenings or weekend. Sometimes I even take vacations just to code on some work-related projects that I find…

> I choose my work places because I genuinely like what I would do there.

That's great and so do I, but I still don't see that as reason to work in my free time. I do some personal projects as well, and those are usually even more interesting but also more beneficial for myself. Of course I still think about stuff from work now and then, maybe I see an interesting solution when casually surfing the web, but I'm not going to do more about that than write a note for the next work day.

> Nothing great has been achieved by teams where people shut down their brain after 6pm.

Citation needed

Edit: Also most teams never work on the next exceptional thing that will be remembered in 30 years, so why work as if it was?

Re: Things they didn’t teach you about software engineering

#160

Post by marginalia_nu » Sat, Jan 07, 2023, 1:35 PM UTC

quanticle wrote: post #27

Rare work-life balance. In other professions, your work day ends at 18:00, and you forget about the job. Not here. You will most likely always be online and checking the code, even in the evening. If that's the case, quit immediately. I've been in this industry for over a decade (oh god, has it been that long already?) and I have never had a job where I was "always online and checking the code, even in the evening".…

It's not always the job. Sometimes it's the person. Had a junior developer I literally had to shoo away from his desk at the end of the day, otherwise he'd keep working until 9 PM.

I tried to tell him: Nobody asked this of him. He didn't need to prove himself, it wasn't on his back if we didn't meet the deadline, it wasn't worth sacrificing his health and the relationship with his wife and more than likely burning out before 30.