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

Things they didn’t teach you about software engineering

vadimkravcenko.com

Post reply on HN
Print view View original

61–70 of 285 posts

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

#61

Post by r_hoods_ghost »

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 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 enforce this when someone gets too obsessive about their work(and have done it to myself a couple of times!). I've never had to fire anyone for working too much and dragging down productivity in a team but I've come close a couple of times.

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

#62

Post by sunsunsunsun »

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

Ya this is rediculous. Ive been logging off for years at 5pm, sometimes even 4pm. I don't work for free. Sometimes I have had to work at night but that means I take a few hours off another day when it's slower.

I often think about code at night but only in the context of a personal project.

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

#63

Post by hermanradtke »

sureglymop wrote: post #54
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.

I find debugging hard when it comes to web development. How can I debug a typescript web app when 1. It will actually be in javascript once it's transpiled and 2. It will run in the browser and not in my ide. It uses some kind of live reloading dev server that is completely different than the production build. Currently I'm building something with sveltekit and i have no idea how to debug this except logging out mess…

Most languages are compiled or transpired into another representation.

For TypeScript, source maps can help with the debugging.

The live reloading dev server is just a wrapper around your code. You should still be able to use the browsers debugger to set a breakpoint at the function you want.

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

#64

Post by 8note »

surfsvammel wrote: post #6

Some more: The worst are when you run into code that’s been around for a long time, but obviously doesn’t work, but which have stuff built on top of it relying on it not to work. When two bugs manifest together in one symptom, the engineering approach that you have learned about breaking a problem down and testing one thing at a time, might not be enough to find the issues. All projects are chaos, learn to accept tha…

Said dependencies on bugs are some of the most interesting things to document, because they're non-obvious, and hard to change

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

#65

Post by jdougan »

josephg wrote: post #49
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.

I also find it odd that nobody is ever taught to read code. We spend a lot of time writing code, but how many programs does the average CS grad read by the time they graduate? Imagine going to school to learn how to write, but in the course nobody ever reads anyone else's work. And in fact, most people (including the professors) never read any books. For some reason, thats the status quo in software. In industry, lea…

You might find this interesting https://www.dreamsongs.com/MFASoftware.html:

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

#66

Post by Galanwe »

r_hoods_ghost wrote: post #61
Galanwe wrote: post #39

Earlier quoted context omitted.

> 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 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 super interesting and wouldn't have enough focused/dedicated time on normal business days.

Overall the whole hard distinction between work and non-work is overstated IMHO. I choose my work places because I genuinely like what I would do there.

I will even go further: If I end up with colleagues that are _not_ genuinely interested in what we do to at least think about interesting problems in their free time, then it's a bozo job, I don't want to work with these people. Nothing great has been achieved by teams where people shut down their brain after 6pm.

Now don't get me wrong, I understand that there are gruntwork places out there, where the job is writing braindead CRUD apps all day long, and I wouldn't want to think about it after-work. But then again, I wouldn't work there on the first place.

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

#67

Post by Galanwe »

quanticle wrote: post #43
Galanwe wrote: post #39

Earlier quoted context omitted.

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

If you're so uninterested by your work that thinking about it after 6pm makes you sick, why did you pick it? Doing anything continuously for long periods without rest is unhealthy, and leads to both declining physical and mental health. Working 10-12 hour days is something that you can do for a short burst, but if you're doing it for months on end, it will negatively impact you. I've been in the industry for 15 years…

I think your comment actually proves my point.

You are admitting that you do think about code outside working hours, though you don't consider it to be work because.. it's code for a hobby project?

That's not a valid point to me. What if your job was open enough that you could find dozens of interesting fun things to code on the side?

That's the job you should be looking for.

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

#68

Post by quanticle »

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…

    Nothing great has been achieved by teams where people shut down their brain
    after 6pm.
Why do you think that the only options are:

1. Thinking about work

or

2. Shutting your brain down

If I want to go hack on some Clojure after work, when the day job is in Python, then what's wrong with that?

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

#69

Post by atemerev »

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…

The difference is a a single question: “do you have family/kids?” This is also the main reason for ageism in the industry, where employers prefer to hire younger people.

I love programming, but I love my family even more.

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

#70

Post by quanticle »

renox wrote: post #51
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".…

I rarely goes online in the evening but when I have an interesting problem, it's not rare that I have a solution when I wake up in the morning! So you don't really stop working at 6pm..

I'll be sure to let my boss know about your definition of "working" when it's time for performance reviews :)
Post reply on HN