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

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

#251

Post by dinkumthinkum » Sat, Jan 07, 2023, 11:15 PM UTC

sorokod wrote: post #95

flohofwoe wrote: post #94

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

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

I kind of think it is very banal and simplistic. A software engineer being primarily concerned with the bottom line, what does that really mean? At sone point you have different levels to a company and engineering is concerned with good engineering and above that are levels concerned with what products you create, features, etc. I’ve heard of CEOs that think that software engineers to think about every line of code in terms of how much value it brings to the company. That is not an efficient division of work will lead to short sighted and task saturated decision making.

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

#252

Post by Insanity » Sat, Jan 07, 2023, 11:18 PM UTC

isityouyesitsme wrote: post #211

Insanity wrote: post #109

Earlier quoted context omitted.

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.

To counter your final sentence. Europe has an absence of religion and has no such work-life balance issues as America. (Speaking from experience on both sides of the big pond)

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

#253

Post by mikrl » Sat, Jan 07, 2023, 11:35 PM UTC

dinkumthinkum wrote: post #241

mikrl wrote: post #179

Earlier quoted context omitted.

You’re either: - management pretending to be a wagie as a psyop - extremely privileged and never had to grit your teeth to pay the bills - going to have a rude awakening when the crop of younger millennials and Gen Z hits your workplace and you realize these bright young things with dreams and desires are only in software because it’s one of the few lucrative careers left in this proto-fascist shithole of a dying civ…

This is pretty extremist. If you think this is proto-fascist, you must not be aware of what fascism is like. As far as a “shithole” or “dying” civilization, I mean what is an example from of civilizations that are tremendously better or more “living?” I would agree that leftist culture is pretty depressing but I GenZ is a good example of the kind of generation that subsequent generations will react against, though it…

Income inequality and social stratification have both increased dramatically in my lifetime, and QoL and resilience of various systems necessary for civilization have decreased.

As far as fascism goes, as you say, these things need time… but I’m sure a yet unwritten history book can enlighten you, right next to the passage on the gen Z backlash.

This is not really relevant, I was merely provoking emotional response for rhetorical effect (a useful and effective tool in the business/realpolitik toolkit)

And I’m sure these younger engineers are happy collecting their paycheques, scheming their schemes and thinking of what to disrupt next with all the free time they have because they roll their eyes at guff like the parent comment. Maybe that’s how we can all be happy.

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

#254

Post by wlonkly » Sun, Jan 08, 2023, 12:16 AM 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…

One model that I picked up somewhere (but I don't remember where), which I teach to anyone willing to listen, is that there's four kinds of dates:

- Estimates (I think it will take X long)

- Targets (I would like to have it done by X)

- Soft deadlines (with low consequences for missing)

- Hard deadlines (with high, usually external, consequences for missing)

and that understanding the model and using those words solves quite a bit of confusion around dates. Of course sometimes targets become soft (or even hard) deadlines because humans are messy, but being able to distinguish those things is a step in the right direction.

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

#255

Post by terminal_d » Sun, Jan 08, 2023, 12:20 AM UTC

auggierose wrote: post #247

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

Everybody agrees counting lines of code is a bad idea to measure progress in programming. Now you say measuring the money it makes is the way to go. Money is not the goal. Money is just another tool. Like VSCode.

I love this comment. It dodges the point so well.

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

#256

Post by moosedev » Sun, Jan 08, 2023, 12:39 AM UTC

fjfaase wrote: post #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 insecuri…

I'm enjoying that interview right now - thanks for sharing!

I also identified with the rest of your post. I've felt regret recently for the career "potential" I lost to the inner struggle, and at around 15 years in, I think I understand these dynamics well on an intellectual level, but emotionally, I feel further than ever from being able to overcome them.

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

#257

Post by guina » Sun, Jan 08, 2023, 12:59 AM UTC

nunez wrote: post #180

I do not at all agree with the "it's not a dream job" section. Please name another career that pays you six figures out of college that doesn't involve several years of additional education, doesn't make you wear suits, is mostly non-life-threatening, is constantly in demand, and doesn't require special accreditations or certificates. If you're spending more than your 40 working and aren't on call, then that is on yo…

I mostly agree with you but want to provide a little disagreement.

It’s not a dream job everywhere for every person. Not everybody is able or has the ambition to put in the work needed to be a top earning or top skilled developer. And even if you are a lot of the “dream” aspect of the job will depend on what country you live in, even in a remote-first world.

But if you’re in America it’s one of the last professions where the American Dream is still possible.

It’s a trade, so the better and more experienced you get the more money you can demand if you’re ambitious. Software also scales better than any business so your work can have an incredibly high level of impact.

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

#258

Post by kimburgess » Sun, Jan 08, 2023, 1:11 AM UTC

osigurdson wrote: post #203

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 lot of this stems from the accepted norm that an estimate is a single value. If we want to estimate accurately, it is necessary to break work down into smaller pieces. However, we can only estimate the items that we can identify at the time of estimation (I.e., we know that we need to do A,B and C but discover that D,E and F are needed as well). The other factor is combinatorial explosion: we'll do A,B or C and…

Completely agree. The overcorrection applies in both directions.

The two value (estimate and confidence) is just a simple approach that is rather intuitive to interpret directly. As you note, diving into 3 point estimates gives to ability to extract beta distribution or other weightings that may or may not be suitable for the given domain.

Complete top down planning for any work that involves discovery is useless, at best. That doesn't mean no planning is better.

(Source: have experienced and been actively involved in both sides of that overcorrection.)

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

#259

Post by hbrn » Sun, Jan 08, 2023, 2:02 AM UTC

bradlys wrote: post #172

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

I disagree with both. Code and business value are worthless. Boss approval is literally everything. It really doesn’t matter if your ideas make a ton of business sense if they are in conflict with your direct manager or any part in the chain of hierarchy. As long as they don’t like what you’re saying - you’re literally worse than worthless. Often this is because your idea isn’t their idea - therefore damage to ego. D…

> Boss approval is literally everything.

This is such a sad corporate loser mentality.

Bosses are humans. They can be wrong. They can be convinced. Even manipulated, if that's your game.

> you’re hired for a job. You’re a glorified and well compensated code monkey

Only if you choose to treat yourself like one. I'm hired for my domain expertise that my bosses lack. I can understand 60-80% of their domain, they can understand 5% of my domain. When I'm saying that feature that they want is a nice-to-have and I don't want to build it unless I see evidence of it's value, they usually listen.

> I’ve yet to meet any hierarchy chains that are truly open minded to a low level IC saying anything that counters them

I worked at multiple startups (between 4 and 100 in size) and I always had a voice, even early in my career. Maybe you're the problem?

> you’ll become a bootlicker and actually make progress in your career rather than being stuck in senior/staff

Where exactly does the bootlicker progress? A code monkey doesn't become VP/C-level through bootlicking, there are plenty others with much better soft skills. At best you'll be a code monkey turned manager (which is worse than staff).

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

#260

Post by randomdata » Sun, Jan 08, 2023, 2:17 AM UTC

yamasanama wrote: post #235

randomdata wrote: post #212

Earlier quoted context omitted.

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.

I agree there is little urgency. After all, if there were, the withholding of information would be devastating, not just annoying.

But you're right that having a low priority Slack channel that you can casually look at when you're at a natural stopping point is way less disrupting than having to drop everything you are doing because the clock says it is meeting time.

I wonder sometimes if people who get engrossed into this meeting culture have just never experienced better? Anything can seem like a good idea if it is all you know.