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

51–60 of 285 posts

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

#51

Post by renox »

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 rarely goes online in the evening but when I have an interesting problem, it's not rare that I have a solution when I wake up in the morning!

So you don't really stop working at 6pm..

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

#52

Post by invalidname »

yamasanama wrote: post #48
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.

Most non-trivial programming homework assignments in college require debugging and a good school will provide guidance of how to do this. One thing I do in job interviews is to have the candidate debug an issue (that they usually caused themselves and that I let them purposefully run into). Quite the eye opener of how they approach bugs.

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.

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

#53

Post by jffhn »

>Domain knowledge is more important than your coding skills

It depends. For hiring I would focus much more on coding skills than domain knowledge.

Reminds me of a company that was getting rid of the expert/developper communication bottleneck/gap by having domain people who code, and said it was much easier to teach the domain to a good developper (who should end up knowing it anyway, possibly in more details than experts themselves, due to formalizing it in actually executable code (requirements often don't even "compile")), than to teach coding to a domain expert.

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

#54

Post by sureglymop »

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.

I find debugging hard when it comes to web development. How can I debug a typescript web app when 1. It will actually be in javascript once it's transpiled and 2. It will run in the browser and not in my ide. It uses some kind of live reloading dev server that is completely different than the production build.

Currently I'm building something with sveltekit and i have no idea how to debug this except logging out messages.

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

#55

Post by randomdata »

cam0 wrote: post #9

I had never seen that cartoon about the "dream job" before, but it's something I've thought about so many times as I've listened to people talk about their dream job or dream employer. It always struck me as strange to dream of labor / dream of being an employee - must be a cultural thing.

There is value in dreaming about your options.

A dream house is another example of this. Let's face, housing is awful. The pie in the sky dream would dream of not needing housing at all, but more realistically I can also dream of a house that makes some things slightly less awful. Dreaming about that house provides me with information that I need to move towards it.

More likely it is a semantic thing. I imagine everyone does something like that, but may not call it dreaming.

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

#56

Post by josephg »

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?

It can. I love using debugging problems as an interview question.

Give the candidate some simple code (~200-300 lines is probably about right) with a handful of failing unit tests. Sit them down, walk them through running the test suite and ask them to find and fix as many bugs as they can in 30 minutes.

It pays to make the first bug trivial (like, a typo or something) and make the subsequent bugs increasingly subtle. You learn an awful lot about a candidate by watching their process.

The hard thing with this sort of question is calibration. Candidates will be able to debug way less code than you think in 30 minutes. It helps to run the code past a few coworkers before giving it to candidates to figure out if its too hard a test.

The surprising thing about this test is that it seems to be really highly correlated with senior engineers. Senior engineers often don't do as well as smart grads at coding problems because we often don't write that much code any more. But senior engineers seem to do waay better than juniors at debugging problems. If I could only get a candidate to do one programming problem, I'd get them to debug code. I think you get a massive amount of signal about whether you'd want to hire someone out of a debugging challenge.

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

#57

Post by invalidname »

sureglymop wrote: post #54
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.

I find debugging hard when it comes to web development. How can I debug a typescript web app when 1. It will actually be in javascript once it's transpiled and 2. It will run in the browser and not in my ide. It uses some kind of live reloading dev server that is completely different than the production build. Currently I'm building something with sveltekit and i have no idea how to debug this except logging out mess…

The first book above has a chapter of various tools in debugging web applications. You can use the sourcemap feature to debug TS.

You are missing out on a lot of amazing capabilities by avoiding the browser debugger. Did you know you can place a breakpoint that will trigger on DOM mutation?

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

#58

Post by randomdata »

yamasanama wrote: post #45
randomdata wrote: post #32

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

> 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 This is an odd meeting culture. Just remove the requirement that everybody has to bring up something. FWIW I've never felt like that in my teams.

I'm not sure it can be removed, fundamentally.

After all, if everyone sent out their emails, so to speak, what would be left for the meeting? I mean, what are the odds of someone discovering something worthwhile to communicate to the team just seconds before the meeting starts? Any earlier and the email would have already been sent and there would be nothing left for the meeting. Maybe it happens once in a blue moon, but regularly across a wide number of people? No way.

I've never attended a status meeting that was completely void of participation, so there must be withholding of information done so to pad the meeting. Not everyone may feel such pressure, but it is apparent that some – and I dare say most – do.

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

#59

Post by rawoke083600 »

Good list ! The one thing I would add or emphasise: Is communication skills

I WISHED in addition to Calculus and CS that some form of "effective communication course" was required up to 3rd year ! Even the "basics" like how to "Respond Vs React (the emotion)"

If you are a coder 90% of the time it's going to be a "social" or "team" activity. And where you find people you find people problems, egos, miscommunications, anger etc !

The amount of time you will have the debate about "how to code something the 'correct' way" will be the cornerstone of your success in a team. That 'debate' about the 'correct way' is hard since CS is such a young "engineering discipline" compared to say how to build a bridge.

I can tell you this, the other coders I worked by far the best with are the coders that can communicate or that I feel 'safe enough/trust enough' to talk honestly and openly and separating yourself from your code ("you-are-not-your-code") becomes automatic with these types of pro-communication programmers.

TL;DR: If you want to be an effective or standout coder: Focus HEAVILY on your communication skill.

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

#60

Post by beebmam »

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?

My children are being raised by a parent that cares about them and makes time for them. I didn't have that privilege.
Post reply on HN