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

31–40 of 285 posts

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

#31

Post by atoav »

gregmac wrote: post #14
orderedtree wrote: post #7

Earlier quoted context omitted.

Why can't debugging be tested?

I can think of a couple challenges. Let's say you're debugging "the website won't load." Often debugging is a hunch, and quickly branches. One person will go down the path of trying the same site from another PC. Another will try a different site from the same browser/PC. Another will try to ping the server. If you're running this live you're always going to have the chance where someone's hunch or first try basicall…

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 would be an ideal answer, judging less ideal answers fairly is certainly a challenge, but not impossible.

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

#32

Post by randomdata »

> Meetings are there to ensure that everything is going smoothly and on schedule.

Are they? At one time in my career you just let people know when something isn't going smoothly/not on schedule. A quick email (or equivalent) was more than sufficient to raise awareness.

For various reasons I eventually fell into this meeting culture. I don't get it. It produces this weird state where everyone saves up what they have to say for the meetings to avoid an awkward lack of participation or "I have nothing" in the meeting, which results in a barrage of mostly useless information, all while the nuggets of gold that the meeting would benefit from regularly get missed because everyone is too overwhelmed by the information overload.

And because everyone saves up what they have to say, the team seems more distant, which diminishes other beneficial outcomes that arise when everyone is regularly chatting with each other. The information lag also dramatically decreases the overall efficiency of the team, not having useful knowledge as it becomes available.

> You might not like it, but the information must be shared for the system to remain efficient.

The thing is, I actually like meetings. After you've recognized something isn't going smoothly, calling a meeting to formulate a plan of attack under the narrow scope of that specific problem at play can often lead to really great outcomes.

But I dare say that if the meeting is there simply to find out that there is a problem, you are doing something wrong.

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

#33

Post by EdwardDiego »

zabzonk wrote: post #4

i thought this was pretty good, the point on aesthetics in particular - how much code have i seen and thought "how could you have written something so ugly?"

At my first coding job, my CEO passed on to me his belief that code that looks ugly should be refactored asap, as the ugliness not only hides, but rather implies, bugs.

He's been right quite often, as I progress through my career.

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

#34

Post by yodsanklai »

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

First, there are of course many professions where you work day doesn't end at 18:00.

As for our industry, I don't disagree with you but I'd be a bit more nuanced. I'm not pressured to work long hours. But I often feel that if I want to reach my goals, I need an occasional coding marathon (which I don't mind because I do like coding, like everybody else doing this job I suppose).

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

#35

Post by randomdata »

HollowMan wrote: post #17
HollowMan wrote: post #16

After 10 years in the industry I agreee with almost every bit. Soft skills are never taught, rarely checked during interviews, but might well be themost important ones.

> Estimations will be asked even when you don't want to give them Actually this particular point reminds me of young-arrogant-me saying things like "I can't give you an estimate since its software, and everybody knows thats estimates are impossible, duh." to my boss. Boy was I young, and arrogant!

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 thought after you've answered.

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

#36

Post by invalidname »

orderedtree wrote: post #7
invalidname wrote: post #3

I like this list. It's also missing "debugging". That's a skill that they don't emphasize in college because they can't test it and it's hard to teach. But there are ways to teach it and techniques. There are some books on the subject: https://www.amazon.com/dp/1484290410/ https://www.whyprogramsfail.com/ That can mitigate that a bit.

Why can't debugging be tested?

I can personally evaluate a specific persons skill. But doing this in a formal gradable test would be hard.

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

#37

Post by quanticle »

yodsanklai wrote: post #34
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".…

First, there are of course many professions where you work day doesn't end at 18:00. As for our industry, I don't disagree with you but I'd be a bit more nuanced. I'm not pressured to work long hours. But I often feel that if I want to reach my goals, I need an occasional coding marathon (which I don't mind because I do like coding, like everybody else doing this job I suppose).

Right, that's the contrast I wanted to draw. In many other professions it is routine and expected that you're available in the evenings or in your off hours to deal with urgent (potentially life-threatening) issues. Programming is not one of those. If you're routinely being called upon to actually work on code in the evening, that's neither normal or healthy.

An occasional coding marathon is fine. I've done it myself, but I don't expect it of anyone else, and if it became a routine expectation (as it seems to be with the author of this post), I would consider it a major red flag.

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

#38

Post by yodsanklai »

intelVISA wrote: post #10
KrugerDunnings wrote: post #5

There is nothing wrong with this article in trying to paint a realistic picture of what is expected of a software engineering nowadays but man am I getting tired of this one sided culture of professional responsibility. I just don't vibe with this advice anymore, like all the same with me but I'm gonna call myself something else then, you can have it.

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

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

#39

Post by Galanwe »

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?

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

#40

Post by yamasanama »

Missing from this list is that lots of the mentioned concepts are highly subjective. There is no generally agreed-upon standard of what documentation is "proper". Or what "clean" code is. Or what "competence" looks like. Or what a "scalable architecture" is. Etc etc. Most of these words are bent by whomever using them to make a point (or to boost their ego, sadly). Two people could easily work side-by-side and claim about the other that that person is incompetent and defend this position here on HN with some horrible-sounding anecdotes.
Post reply on HN