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

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

#261

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

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.

Yes, but what wasn't clear was around the margin of error. I assumed there was an expectation of being close. If I said eight hours and it took nine, close enough. But if I said eight hours and it took a year, that was once concerning, but I eventually learned that I could say eight hours for a year's worth of work and nobody would actually reflect back on it anyway. All that mattered was answering the question with something.

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

#262

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

IshKebab wrote: post #162

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

Depending on what you mean by "code" I disagree. It sounds like you're arguing for "just get it done quickly" vs "take your time and do it right". That isn't a "code vs money" debate it's short term vs long term productivity. Technical debt is a real thing. As is "decision debt" (not sure the official term; I mean where you make the wrong long-term choice because you didn't spend enough time on research / prototypes.…

> "just get it done quickly" vs "take your time and do it right"

There is no such thing as "do it right". There's your flawed and biased perception of what's right, which doesn't take unknown unknowns into account.

> Oops three years later you're locking into Python and your app is slow as hell

Been using Python more than a decade, never had this problem. App slow as hell is always an eng culture problem. Shitty engineers will write slow code in any language. Don't do HFT in Python, don't write web apps in C.

> Producing documentation and commenting code. Don't need it now. 10 years later ...

The need for documentation doesn't skyrocket from 0 to 100 overnight.

Don't need it now? Don't write it.

Starting to feel the need? Start writing a little bit.

The problem is not the decision to not write documentation. The problem is not re-evaluating this decision in 10 years.

(another problem, based on your take, is treating documentation as binary: we either don't do it, or we're going all in)

> We'll just use Make. 5 years later a CI run uses 300 compute hours and 6 wall hours

Do you think every team that uses Make has this problem? Again, sounds like it's a team problem, not tool problem.

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

#263

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

Starwatcher2001 wrote: post #105

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…

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.

Whatever you do with your life, you'll always regret not doing something else.

Grass is always greener.

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

#264

Post by Chinjut » Sun, Jan 08, 2023, 4:10 AM UTC

Galanwe wrote: post #39

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

> If that's the case, quit immediately If you're so uninterested by your work that thinking about it after 6pm makes you sick, why did you pick it? I've been in the industry for 15 years, coding since 25+ years, and I very often think, code, read about work or work related things at any time of the day or weekend or vacation, because I find it interesting. Why would I work in something of no interest to me?

Because I need money to exchange for goods and services in order to live, particularly in order to maintain housing and healthcare.

I would love to be paid to pursue my passions full-time, but that opportunity has not yet arisen. So I split my time accordingly between doing what earns me a living and doing what I actually enjoy in life.

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

#265

Post by invalidname » Sun, Jan 08, 2023, 4:42 AM UTC

yamasanama wrote: post #116

invalidname wrote: post #52

Earlier quoted context omitted.

You would need to debug but can you tell if a person just printed to the console or used advanced tooling? Can you tell how long they wasted on the debugging aspect? Nope. That's the problem. These are soft skills that are hard to teach but much harder to test.

Yes, I can tell, because in the interview situation I'm sitting next to them. And print statements are sometimes the superior choice. This ties into my other comment that these things can be heavily subjective. As long as it gets the job done, I prefer print statements used by somebody who uses them as a sharp knife to gain understanding of what's going on over somebody just clicking buttons in a fancy UI but has no…

I'm talking about universities not interviews.

Print debugging is sometimes useful but sometimes indicate the person doesn't know about tracepoints/logpoints.

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

#266

Post by lionkor » Sun, Jan 08, 2023, 6:20 AM UTC

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

Im not working a second im not being paid - its fun, sure, but its not that fun that i'll work for free.

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

#267

Post by aryehof » Sun, Jan 08, 2023, 6:46 AM UTC

Touching on domain knowledge, reminds me that there are different types of software applications, yet I rarely see any differentiation. There is just “software”.

Much of the audience and discussion here on HN revolves around applications in computing, the computer and data sciences, and software infrastructure. For this purpose, “external” business domain knowledge and value is of little interest?

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

#268

Post by Too » Sun, Jan 08, 2023, 7:58 AM UTC

roncesvalles wrote: post #236

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.

The execution by swe can still take 10 times longer depending on if you go with a proven, quick and dirty straightforward YAGNI solution vs reinventing the wheel in latest cool fad, with hundred layers of abstractions and configurations in beautifully crafted code in the most poetic rube goldberg machine you have ever seen.

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

#269

Post by atoav » Sun, Jan 08, 2023, 9:14 AM UTC

no1lives4ever wrote: post #154

atoav wrote: post #31

Earlier quoted context omitted.

Sure testing a beginner is hard here. But testing someone who learned how to debug means testing their knowledge of the moving parts of the system they are debugging. And this can be explained by the person being tested. E.g. "I am going to ping an IP on the outside first, to see if ICMP message reaches the outside server. If yes I will check if the DNS server responds, if no we check the physical connection." That w…

And what if the firewall blocks icmp? What if the dns server is internal to the network and is returning a stale ip? There are way too paths down this rabbit hole.

I mean if it is a test you obviously test things that you tought them first, or not?

Of course in reality there can be more, weirder things — especially if you are coming into an unknown network. But we are talking about an educational context here, would not make a lot of sense to let your students run into new unknown issues on a test unless your goal is not to educate.

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

#270

Post by tigerlily » Sun, Jan 08, 2023, 10:00 AM UTC

FlyingSnake wrote: post #88

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

> Unless you’re in charge of coding a nuclear reactor core or similar

If I'm managing this one, then you're definitely going home on time and getting a break from work each day.