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

71–80 of 285 posts

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

#71

Post by quanticle »

Galanwe wrote: post #67
quanticle wrote: post #43

Earlier quoted context omitted.

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.

    What if your job was open enough that you could find dozens of interesting
    fun things to code on the side?
No job is that open. From your other comment in this thread:

    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.
I guess I'm fortunate in that I don't really have that many meetings or calls, and I don't have to spend my weekends and evenings doing programming. I get to do mostly programming during the day. Then, in my off hours, I have the option of programming. But I also have the option of doing other things, like watching TV or reading a book, or going for a bike ride.

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

#72

Post by HellDunkel »

KrugerDunnings wrote: post #30
edwardsdl wrote: post #8

Earlier quoted context omitted.

Can you elaborate on what you mean by “one sided culture of professional responsibility”?

> Highly unlikely that you will make a meaningful difference in the world This is an example of negative self talk, stop this, the reason you are broken is because you are trying to fix something, this just leads to more anxiety. Most self-improvement content by developers for developers tends to be very negative like I can't explain it really well but to compare it to this sketch: https://www.youtube.com/watch?v=85H…

I did not perceive it as a self improvement piece that much but you are absolutely spot on: the professional responsibilities are unevenly distributed.

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

#73

Post by kimburgess »

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.

There’s a whole set of more formal systems such as PERT (https://en.m.wikipedia.org/wiki/Program_evaluation_and_revie...) which base off this principle. That doesn’t work for every project, but there’s often an over correction in ‘modern’ software teams where significant research, experience, and process that has been designed to avoid project chaos is completely ignored for the sake of being ‘lean’.

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

#74

Post by lazyasciiart »

atemerev wrote: post #69
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…

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.

And that's why I only work about half the day during 9-5, and the other half after 6pm. Because little kids don't disappear from 9-5pm and I like spending time with them.

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

#75

Post by dieselgate »

yodsanklai wrote: post #38
intelVISA wrote: post #10

Earlier quoted context omitted.

Whoever wrote this hit the enterprise koolaid a bit too much, you're meant to sip not swallow. Calling SWE "working in IT" is where it lost me.

(foreign speaker, genuinely curious) How would you phrase it? working in ...?

Not sure what your native language is (for Spanish speakers "working on", "working in", "working at" could be a reasonable distinctions) but think the punchline is that it's software "development" or "engineering" and not simply "IT". Although some may argue they all fall under the same general label as being IT (i'm not opinionated)

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

#76

Post by red_admiral »

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

That might be the case in startups (one of the other articles on the same author's page is "Lessons learned from becoming CTO of a small startup"). One of the reasons why some developers choose to work for faceless big megacorp rather than cool aspirational startup is that there are megacorps where you log off and go home at the end of your working day, along with everyone else.

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

#77

Post by lazyasciiart »

quanticle wrote: post #71
Galanwe wrote: post #67

Earlier quoted context omitted.

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.

What if your job was open enough that you could find dozens of interesting fun things to code on the side? No job is that open. From your other comment in this thread: 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. I guess I'm fortunate in that I don't really have that many meetings or calls, and I don't hav…

> No job is that open

Mine is.

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

#78

Post by arcturus17 »

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…

> Sometimes I even take vacations just to code on some work-related projects that I find super interesting

> what we do to at least think about interesting problems in their free time, then it's a bozo job

> Overall the whole hard distinction between work and non-work is overstated IMHO

Look, I continue to code and study in my free time, and I am still passionate about learning SoftEng and CompSci fundamentals, but the shit you're saying sounds super-sad and I definitely wouldn't want to work with someone who takes vacations to work on _work_ problems, either.

I'll take a seasoned and passionate engineer who has a family (even though I don't have one!) and has to work around that any time of day. In the vein of what GP was saying, bounds on limited resources like time can produce very effective work habits and conversely, seeing time as an unbounded resource (which is a phallacy anyway) sounds like the recipe to have a culture of sociopaths.

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

#79

Post by pjerem »

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

It really depends on each person. Maybe it’s an ADHD symptom, maybe it’s just me, but I stop thinking about work as soon as I shut down my computer.

And it’s not about wether I like my work or not, it’s just that I have more important things to think about or that I just let my mind wander.

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

#80

Post by jsmeaton »

fhd2 wrote: post #26

"Estimations will be asked even when you don't want to give them" I think usually it's not a matter of not "wanting" to give them. It's a matter of not wanting to take a wild guess - which is talked down if it seems too high - and then be asked to finish the work in that time frame. Time or scope, at least one of these things needs to be flexible, and stay flexible until the work is done.

Estimates are not commitments. More people need to understand and accept this.

You’re on the money about time and/or scope needing to be flexible. Estimates improve as you gather more information and complete parts of a project. Providing early feedback that relates to the original estimate is key!

“This is more complex because of X, and will likely add Y time. Do we want to proceed?”

Nothing worse than getting to the end of an original estimate and only then letting a project owner know it’s going to be twice as long.

Post reply on HN