Live data from Hacker News

Things they didn’t teach you about software engineering

vadimkravcenko.com

121–130 of 285 posts

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

#121
Something I would like to add to the list (being in the field for 33 years):

Discover that your greatest struggle is with your own deep rooted sense of insecurity,

I think that software engineering, like no other form of engineering, has an aspect of creativity (source code), in combination with many (often hidden) single points of failures (bugs), where cooperation with others is essential, causing all your insecurities to be revealed.

Either you learn to hide these or they drive you on a road to soul searching, possibly resulting in various forms of burn-outs, in alienation from your family and friends outside of you work circle, in changing your world view and/or losing your faith. But which might in the end result in a form of enlightenment.

I am aware that there are some other professions where this also is the case. Just this week, I watch an interview with the neurosurgeon Henry Marsh. You can watch it here (with some Dutch subtitels and advertisements): https://www.npostart.nl/vpro-wintergasten/04-01-2023/VPWON_1...

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

#122

Earlier quoted context omitted.

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?

> If I want to go hack on some Clojure after work, when the day job is in Python, then what's wrong with that? That is of course perfectly fine, but to me that represents a not-so-ideal fit between your interests and your job. Realistically, you will spend more engineering time on your job than on your hobby project. From my experience, that means my out-of-working-hours projects tend to be driven by needs or limitat…

    That is of course perfectly fine, but to me that represents a
    not-so-ideal fit between your interests and your job.
If the day job were Clojure, I'd be hacking in Python in my spare time. Or some other language (Rust, Haskell, etc.). Or not even hacking at all, but reading a book, or doing something else. The entire point of having hobby projects for me is that they're not what I'm working on during the day. They're an opportunity to broaden my horizons.

    Me and a coworker started to dig into glusterfs to solve our
    issues. We spent months reading the code on our free time, reading
    papers on distributed filesystems, fixing issues in our fork
    (hoping that RH would pick up maintenance after the transition).
That just sounds like a lot of unpaid overtime to me. It sounds like you enjoyed it, but I'd find that experience absolutely miserable. Working intensely on a project is great, but I need time where I'm thinking about something completely different, otherwise I burn out fast.

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

#123
post #99
post #85

Earlier quoted context omitted.

You are not describing interest, you are describing obsession. I love being a software engineer, still, my family is orders or magnitude more important than my employer’s codebase. I really don’t care about my code architecture issues at work when I play Legos with my son or when I ask my wife if she had a good day while cooking together. And I say that while currently working for a good employer on interesting topic…

> You are not describing interest, you are describing obsession. I'm describing passion. > love being a software engineer, still, my family is orders or magnitude more important It's not mutually exclusive... I wake up at 6am, usually because that's the time my son wakes up. I spend around 30m with him until my wife takes over. Then I work on some stuff from 6:30 to 8:30 before the rush of the day starts. My wife doe…

I don’t see much wrong with your schedule if it suits you.

Keep in mind that many people are passionate about multiple things and it is ok that they are not coding related. Please, just don’t assume I am not passionate about my job if I spent “only” 8 hours a day on it on average. There are just more things I am passionate about and I have only one life to live.

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

#124
post #113

Earlier quoted context omitted.

I suspect this may be a 'cultural' issue: For instance in Germany with its strong engineering tradition, nobody in their right mind would call somebody who builds software an 'engineer' (there are some google hits for "Softwareingeneur" but I bet this has a fairly recent thing and has been leaking back from English). A person who builds software is simply called a 'programmer' or 'developer' here. And I really have m…

> Out of interest what are the different skillset requirements between 'software engineering' and 'programming'? Because I really can't think of any. You can look up "software engineer vs programmer".

These all lead to articles which basically come down to separate 'architect vs implementer' roles, which is a long outdated view on how software development works.

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

#125

> Code is secondary. Business value is first. Eh, what a predictable and boring attitude :/ This advice makes sense in a company environment, but there's so many other motivations to write code than just 'business value'. And from what I've seen, focusing on 'business value' alone is the only explanation why so much software written in company settings is so user-hostile nowadays. My counter-hot-take: focusing on bus…

eh.. in my experience those who always spent time sharpen their knifes barely create anything useful, even code looks mediocre because they only want to play so what they write against are likely to be some non realworld puzzle. And "But I write a compiler" is also that.

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

#126
post #51

Earlier quoted context omitted.

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 typically stop thinking about work entirely after I clock out. I already spent most of the day on the problem, and that exceeds my natural interest in it.

[dead]

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

#127

> Code is secondary. Business value is first. Eh, what a predictable and boring attitude :/ This advice makes sense in a company environment, but there's so many other motivations to write code than just 'business value'. And from what I've seen, focusing on 'business value' alone is the only explanation why so much software written in company settings is so user-hostile nowadays. My counter-hot-take: focusing on bus…

eh.. in my experience those who always spent time sharpen their knifes barely create anything useful, even code looks mediocre because they only want to play so what they write against are likely to be some non realworld puzzle. And "But I write a compiler" is also that.

There are a lot of useful things that don't have any business value, also in software. There is no business value in writing and maintaining a compiler for instance (not anymore at least), yet without compilers, no software with 'actual business value' could be created.

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

#128
post #113

Earlier quoted context omitted.

> Out of interest what are the different skillset requirements between 'software engineering' and 'programming'? Because I really can't think of any. You can look up "software engineer vs programmer".

These all lead to articles which basically come down to separate 'architect vs implementer' roles, which is a long outdated view on how software development works.

This is true. "software engineering" was very terrible trauma back in university. It's almost nothing about coding, it's waterfall and a bunch of diagrams. I still think "software engineer" could be overloaded to mean something related to performance .. and architect, and some other things that's not related to coding style or even algorithm.

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

#129
post #39

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?

[dead]

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

#130

Earlier quoted context omitted.

> Estimations will be asked even when you don't want to give them Actually this particular point reminds me of young-arrogant-me saying things like "I can't give you an estimate since its software, and everybody knows thats estimates are impossible, duh." to my boss. Boy was I young, and arrogant!

When I was young I didn't want to give them because I thought they had to be accurate, and pined over being wrong, wasting hours trying to ensure I covered all my bases and basically doing the work to get there. I was quite good with accuracy, which helped feed my belief, but the effort to be accurate was monumental. Thankfully, I eventually came to realize that you can choose a random number. Nobody gives it another…

I think it's literally what the word estimate means though. There's a reason people use the word estimate and not prediction. They want to know whether it's going to take 3 days, 3 months or 3 years.
Post reply on HN