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

231–240 of 285 posts

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

#231

Post by quanticle »

pc86 wrote: post #192
FlyingSnake wrote: post #88

Earlier quoted context omitted.

I lead a fairly large team and I agree with this comment. It is certainly possible and healthier to disconnect from work after 17:00. Unless you’re in charge of coding a nuclear reactor core or similar, your CRUD app can always wait. A streamlined on-call process should be in place instead. Taking care of your headspace and unwinding at end of the day should be one of the most important routines in a programmer’s lif…

> A streamlined on-call process should be in place instead. Honestly even 99% of non-nuclear reactor code doesn't need on call. Most of the time it can wait until the morning. Amazon? Sure, have on call. Your app that's used by businesses during the business day? Fix it tomorrow.

The part of the paragraph that really bothered me wasn't the hours, actually. It was the implication that you would be expected to code during those hours. Even when I've been on-call, I've never expected to write code, outside of business hours, during my on-call shifts. Update configuration? Sure. Roll back a broken deployment? Absolutely. But if devs are writing significant amounts of code (beyond 10-line patches, or updates to config files) in order to put out operational fires, that's a big red flag. It means that the codebase hasn't been designed to be easily changed with configuration. It means that deployments are so difficult, it's easier to try to write a patch in the moment than it is to roll back and see what went wrong in the morning. Furthermore, any code that is written under that kind of pressure isn't going to be high quality. It's going to be code that does the minimum necessary, with no documentation or unit tests. It's tech-debt equivalent of a high-interest payday loan.

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

#232

Post by the_only_law »

gernb wrote: post #92

> Remote work can lead to isolation. Depending on the company and team structure, software engineers may work in solitude (not including video calls) for long periods, leading to a lack of real social interactions. Yep > Rarely you're building something you love. More often than not, it's tedious work that needs to be done You should switch jobs. The majority of my jobs were building something I love > It's hard work…

> You should switch jobs. The majority of my jobs were building something I love

Lmfao if they would hire me I would.

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

#233

Post by jsmeaton »

philipwhiuk wrote: post #214
jsmeaton wrote: post #80

Earlier quoted context omitted.

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.

It can be taught and there has to be general agreement. Building trust with early feedback as scope/complexity changes is crucial.

Wishing is indeed a terrible plan. Teams that treat estimates as commitments are dysfunctional. Estimates are a tool for budgeting in an agile-like world, and need to be refined as progress is made.

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

#234

Post by badpun »

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

This works in non-dysfunctional organizations only. In dysfunctional ones, the inmates are running the asylum and you will be scoffed at if your code doesn't follow the latest trends and buzzwords (e.g. functional programming). Nobody represents the business value - the product owner cares only about features being delivered and doesn't care (or, usually, understand) how the engineers do it, and the engineers are busy outnerding each other with "cool" tech. If you'll propose simple solutions using old and reliable tech, the team will think you're a lazy moron.

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

#235

Post by yamasanama »

randomdata wrote: post #212
yamasanama wrote: post #209

Earlier quoted context omitted.

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

Not all issues are urgent. Most issues I encounter in my job are not urgent. Sometimes it's not even issues, perhaps just a random but interesting observation. It can be less distracting to the team to bring them up next time you have a regular team meeting scheduled, instead of blasting it into a slack channel or even calling a specific meeting. That's what sync ups are good for.

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

#236

Post by roncesvalles »

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

Unless you're in a Also, maybe my perspective is skewed from only ever working at gigantic companies but what usually grows a career is making your manager's life easy - becoming someone who reliably gets shit done on time and without drama.

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

#237

Post by bjornsing »

zmgsabst wrote: post #227
bjornsing wrote: post #220

Earlier quoted context omitted.

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

Except that doesn’t happen: “Janitor” and “physician” are different kind of cogs. What actually happens is that you don’t build the depth in your janitorial department that trades require — so the overall quality decreases. “Janitor” and “physician” are different teams: they don’t “play the same sport”.

In healthcare, yes, and everybody understands that.

In software engineering, not so much. I think the OP illustrates that fairly well. What he’s describing is a janitorial job, but he clearly thinks he’s a physician, and he has written a blog post titled “What it’s actually like to practice medicine”.

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

#238

Post by [deleted] »

mmcnl wrote: post #130
randomdata wrote: post #35

Earlier quoted context omitted.

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.

[deleted]

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

#239

Post by lazyasciiart »

isityouyesitsme wrote: post #210
lazyasciiart wrote: post #77

Earlier quoted context omitted.

> No job is that open Mine is.

I guess with a sample size of 1, I would also be tempted to make sweeping generalizations on an entire industry if the sole same was my own experience.

You're clearly trying to be dismissive of someone, but the overly complex sentence structure makes it hard to tell who you are misrepresenting.

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

#240

Post by astura »

>It's not a dream job

Its a dream job for me and would be for 90%+ of my friends. I suspect anyone saying this has very little life experience. All jobs involve work (duh) but software pays very well, is in demand, only requires a bachelor's degree, and is very chill with a very good work-life balance.

If you're working unpaid overtime then get another job. I've only worked about 3 hours unpaid overtime in my 16+ year career. I've willing worked paid overtime a few times, but not often.

If software isn't close to a dream job then I'd like to know what is.

Post reply on HN