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

101–110 of 285 posts

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

#101

Post by sorokod »

flohofwoe wrote: post #97
sorokod wrote: post #95

Earlier quoted context omitted.

Worth stating nevertheless as the article is about a software engineer. Not a programmer, coder or hacker.

And that's exactly my other gripe! :D Those are all the same, the best programmers in the world (those in the demo scene) call themselves 'coders'. Calling yourself a 'software engineer' reeks of elitism, no matter how much time you spent at university.

I don't see any elitism. You may notice that some of the points explicitly deemphesiz coding and some don't mention coding at all.

The way I see it, coding skills are necessary but not sufficient to claim the SE title.

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

#102

Post by valenterry »

kimburgess wrote: post #73
osigurdson wrote: post #28

>> Managers like numbers, estimates, and asking for estimates with an idea written on a napkin. It's just how the real world works — a business has some monetary goal, but before committing to it, it needs to understand how much it will cost. I think everyone squirms when asked to make a prediction with too little information. If you want to see a developer squirm. ask for an estimate for how long it will take to bui…

A lot of this stems from the accepted norm that an estimate is a single value. This loses a lot of information and when combined with other lossy estimates, this error compounds. Pair any estimate (time, cost, effort) with a confidence indicator. This will likely improve as more about the problem is known, but until then gives the ability to reason with appropriate certainty based on a set of inherently noisy priors.…

Exactly. As a minimum, it should be something like "90% chance it will be between 3 and 10 weeks, 50% chance it will be between 5 and 6 weeks".

Optimally we have a probability distribution.

Not to forget that over time the confidence will grow and estimates become more precise.

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

#103

Post by flohofwoe »

goodpoint wrote: post #98
flohofwoe wrote: post #97

Earlier quoted context omitted.

And that's exactly my other gripe! :D Those are all the same, the best programmers in the world (those in the demo scene) call themselves 'coders'. Calling yourself a 'software engineer' reeks of elitism, no matter how much time you spent at university.

Not at all. Software engineering is very much a thing and requires a different skillset than programming.

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 my doubts that there's any meaningful difference between what's called a 'software engineer' in the US and a 'programmer/developer' in Germany. Building software requires creativity, planning, experience, rationalism and problem solving abilities, all in the same person. If you don't have that, then don't call yourself a 'programmer' ;)

Out of interest what are the different skillset requirements between 'software engineering' and 'programming'? Because I really can't think of any.

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

#104

Post by tapanjk »

> One way I have found to be effective is to focus on being productive despite the other person. I try to find solutions/alternatives that may be more effective and don't require involving the ineffective person.

This above line may sound arrogant because it sort of implies that you are the smartest of the lot. For all you know, you may be the incompetent one for someone else.

However, this attitude (without being a pr*ck about it) can be very useful in navigating your way through the messy reality and becoming more productive in spite of it. It will prevent (or reduce) a lot of "you should have said this before", or "I should have known this before", or "you cannot change that now", or "who wrote this code?" moments.

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

#105

Post by Starwatcher2001 »

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'm 62 and have been in this industry for 40+ years. The BIGGEST regret in my entire life has been the time I spent as a young man working stupid hours on "super important" jobs, and missing seeing much of my kids growing up.

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

#106

Post by quadcore »

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

So you don't really stop working at 6pm..

I've started billing that. Not always, rarely in full, but I bill some of it. It's not just for the money but started more like "what exactly do I work? Best way to know is to bill it".

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

#107

Post by Galanwe »

quanticle wrote: post #68
Galanwe wrote: post #66

Earlier quoted context omitted.

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

> 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 limitations I encounter at work.

I then find it more optimal to embrace and leverage that relationship between during-working-hours and out-of-working-hours projects.

This is the best of both worlds, you get work on more green field projects, have flexibility to choose what you work on, under the constraint that it solves something for your job, but under the assumption that your side projects are anyway often inspired by work, it's a fit by construction.

Let me give you an example:

Some years ago I used to manage some high performance computing cluster, with storage nodes attached to compute nodes as the jobs were very IO intensive. We used glusterfs, which at the time got acquired by RH and maintenance stopped. 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's an example of an out-of-working-hours project, inspired by work, that got used at work, and thus counts as work, while still being very interesting.

This is just an example, but overall I kept that mentality and have been doing that kind of things for more than a decade. You just need to find the right job where you have 1) interesting problems to solve that inspires you to do more 2) the freedom to push your projects 3) the drive to work out of office hours to prove that your projects are worth it and push them.

All the colleagues I have respect for do the same. And someone that does not have this spirit, for me, is not someone I want to work with.

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

#108

Post by kqr »

kimburgess wrote: post #73
osigurdson wrote: post #28

>> Managers like numbers, estimates, and asking for estimates with an idea written on a napkin. It's just how the real world works — a business has some monetary goal, but before committing to it, it needs to understand how much it will cost. I think everyone squirms when asked to make a prediction with too little information. If you want to see a developer squirm. ask for an estimate for how long it will take to bui…

A lot of this stems from the accepted norm that an estimate is a single value. This loses a lot of information and when combined with other lossy estimates, this error compounds. Pair any estimate (time, cost, effort) with a confidence indicator. This will likely improve as more about the problem is known, but until then gives the ability to reason with appropriate certainty based on a set of inherently noisy priors.…

A single value isn't the problem -- the lack of an indication of confidence is. If I say "there's a 90 % chance it's done before March 13." that's a useful and verifiable estimation, even though it's only one number.

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

#109

Post by Insanity »

Galanwe wrote: post #99
pjerem wrote: 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 think the interesting parties to answer that are your wife and kid (in the future). There is subjectivity in what constitutes “enough”.

And there is also quality vs quantity. Each family is obviously different.

As friendly advice, have an open conversation with your wife about that. Speaking from personal experience, I definitely had months where I thought I was balancing my time well enough and my wife disagreed.

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

#110

Post by brazzy »

kqr wrote: post #108
kimburgess wrote: post #73

Earlier quoted context omitted.

A lot of this stems from the accepted norm that an estimate is a single value. This loses a lot of information and when combined with other lossy estimates, this error compounds. Pair any estimate (time, cost, effort) with a confidence indicator. This will likely improve as more about the problem is known, but until then gives the ability to reason with appropriate certainty based on a set of inherently noisy priors.…

A single value isn't the problem -- the lack of an indication of confidence is. If I say "there's a 90 % chance it's done before March 13." that's a useful and verifiable estimation, even though it's only one number.

It's two numbers.
Post reply on HN