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

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

#211

Post by isityouyesitsme » Sat, Jan 07, 2023, 5:30 PM UTC

Insanity wrote: post #109

Galanwe wrote: post #99

Earlier quoted context omitted.

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

Every conversation in this thread where someone implies what is "enough" "passion" or "accomplishment" makes me agree more with unionizing the industry.

It's as though the absence of religion in modern life has left a vacuum of comradery and dogmatism, so they let work fill it.

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

#212

Post by randomdata » Sat, Jan 07, 2023, 5:35 PM UTC

yamasanama wrote: post #209

randomdata wrote: post #202

Earlier quoted context omitted.

> I've not had this for the last 10 years, so it can definitely be removed. You’ve sat in regularly scheduled silence for the past 10 years and people still show up? > Obviously everybody is welcome to bring up whatever is interesting nd worth discussing But logically they would have already said it when it first became interesting, unless they felt pressure to pad a scheduled meeting with content, withholding inform…

I don't understand what you are talking about. Obviously we don't sit in silence. Some things are just easier to discuss in a meeting than over 100 Slack messages. Those things we discuss in meetings.

Right. Like I said in the first comment, after you know there is a problem, calling a meeting to discuss that problem can be quite fruitful. You only need 1 Slack message to say “Hey guys, this isn’t going smoothly. Can we talk?”

The original context was about meetings intended to let others know there is a problem. A time to allow you to say things aren’t going smoothly. But why would you wait for a meeting to let others know there is a problem?

The only reason is because you feel pressure to ensure the meeting isn’t silence. Otherwise you would have logically made it known long before. What is really gained in withholding information from the team?

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

#213

Post by dinkumthinkum » Sat, Jan 07, 2023, 5:42 PM UTC

rco8786 wrote: post #146

fatneckbeard wrote: post #140

Earlier quoted context omitted.

money is not the goal. providing a useful and valuable product or service to customers is the goal.

Totally incorrect, at least in a business context. If it were the case, you would build that useful and valuable product and then give it to your customer for free. But you would never, ever, do that (unless it was specifically as a loss leader for other products) because making money is the goal.

That’s not true because giving it away would mean you wouldn’t be able to produce the product.

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

#214

Post by philipwhiuk » Sat, Jan 07, 2023, 5:47 PM UTC

jsmeaton wrote: post #80

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 th…

> More people need to understand and accept this.

Wishing upon a star that people are better is a terrible plan.

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

#215

Post by wankle » Sat, Jan 07, 2023, 5:56 PM UTC

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

"What important truth do very few people agree with you on?"

For me it's that Apache is the best web and proxy server, Java is the best programming language and platform, Eclipse is the best IDE and never use anything made formerly or currently by Russians including nginx and JetBrains' stuff.

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

#216

Post by acedTrex » Sat, Jan 07, 2023, 6:01 PM UTC

The value section is great, code is worthless unless it DOES something.

I especially appreciate the aesthetic section as i constantly struggle to explain that concept to people on a line by line basis

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

#217

Post by whateveracct » Sat, Jan 07, 2023, 6:04 PM UTC

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

> If you want to stand out in your career - take this to heart. Code is not the goal. Money is the goal, code is a tool to get the money. You work in a capitalistic business, whether you like it or not.

On the flipside, you can be like me and be "meh" about business value (or at least, not a maximalist about it) and treat code as the point and fun/art/etc (easy to do with an FP language, for example). You'll still deliver value and even squeak in some fancy code that isn't the best business value.

The result? Over the years, your employer(s) effectively subsidize your code-for-fun's-sake using the money they make from business value others focus so much on :)

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

#218

Post by roflyear » Sat, Jan 07, 2023, 6:20 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".…

I was trying to get my current company to cover our cell bills because everyone messages us all the time at all hours, even past midnight. When I talked to the c levels they said there's no expectations to reply off hours so they won't cover our cells because they don't want to promote that atmosphere. I turned off all notifications and it's much better tho I think people are starting to get annoyed

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

#219

Post by as1992 » Sat, Jan 07, 2023, 6:22 PM UTC

wankle wrote: post #215

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

"What important truth do very few people agree with you on?" For me it's that Apache is the best web and proxy server, Java is the best programming language and platform, Eclipse is the best IDE and never use anything made formerly or currently by Russians including nginx and JetBrains' stuff.

I mean irrespective of Apache/Java/Eclipse, saying to never use something made by someone just because it was developed by a company/people of a certain nationality is just silly.

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

#220

Post by bjornsing » Sat, Jan 07, 2023, 6:24 PM UTC

zmgsabst wrote: post #163

bjornsing wrote: post #115

Good write-up. But to me this reads more like “Everything I dislike about ‘software engineering’”, and this question pops up in my mind: isn’t there some way around all this? I know this is kind of an unpopular opinion, but I think an important reason we end up with this kind of work environment is that we have no formal division of labor into separate professions. Compare e.g. with healthcare: I sometimes jokingly e…

This is something I talk about with SDE teams I’m coaching: - we’re like a football team - and that means it’s okay we have different roles that utilize our unique skills - or because we need a single play caller - but that doesn’t mean your role isn’t important; QBs can’t work with no linemen - and managements job is to be high level direction, staffing, and play calling - but they need to step back and let the peop…

> I just wish we could get to a paradigm of “team building” instead of “fungible cogs in the process chart”. Both sides, employees and employers, would be happier.

Sadly I’m not so sure about that. If you’re mostly cleaning toilets in a hospital then you would benefit greatly from confusion about your role, so that you can have a bit of the compensation and recognition of a senior physician. In fact when there is a wide distribution of ability a clear majority benefits from this confusion.

I think the reason it works in football is that (almost) anybody can judge ability, so the confused state cannot be maintained for very long.

But sure, with exceptional leadership that will stick their neck out to “give credit where credit is due” you can get around this. It’s just very rare.