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

201–210 of 285 posts

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

#201

Post by croes »

sirsinsalot wrote: post #194
croes wrote: post #187

Earlier quoted context omitted.

>Money is the goal, code is a tool to get the money. You work in a capitalistic business, whether you like it or not. Pu Capitalism and money are actually only the means to an end, to achieve the best possible for society. But as is so often the case, at some point the means becomes the end.

As if capitalism in practice has ever been about the best outcome society wide. It's about a means of allowing wealth disparity while the have-not masses are too distracted to get out the guillotine

You are still confusing the means with the end.

It is not about what capitalism is about, it's about why society chose capitalism instead of other forms of economy.

That's why capitalism needs laws to tame it's worst excesses.

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

#202

Post by randomdata »

yamasanama wrote: post #118
randomdata wrote: post #58

Earlier quoted context omitted.

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

> I'm not sure it can be removed, fundamentally. I've not had this for the last 10 years, so it can definitely be removed. Obviously everybody is welcome to bring up whatever is interesting nd worth discussing, and that's what we do in my current and previous workplaces. But there should not be a requirement that everybody has to bring up sth, which would lead to the described issues..

> I've not had this for the last 10 years, so it can definitely be removed.

You’ve sat in regularly scheduled silence for the past 10 years and people still show up?

> Obviously everybody is welcome to bring up whatever is interesting nd worth discussing

But logically they would have already said it when it first became interesting, unless they felt pressure to pad a scheduled meeting with content, withholding information from the group until the meeting takes place. So, again, what’s the point of sitting in silence or purposefully denying the team information to satisfy the social pressure?

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

#203

Post by osigurdson »

kimburgess wrote: post #73
osigurdson wrote: post #28

>> Managers like numbers, estimates, and asking for estimates with an idea written on a napkin. It's just how the real world works — a business has some monetary goal, but before committing to it, it needs to understand how much it will cost. I think everyone squirms when asked to make a prediction with too little information. If you want to see a developer squirm. ask for an estimate for how long it will take to bui…

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 this impacts what we do next. This graph can become enormous when attempting to construct up-front.

I agree that having a probability distribution for each estimate is better than a single value. If you have two values, this is a uniform distribution. It is also possible to do a normal distribution, triangular, truncated normal, etc. However, it isn't clear to me that increased sophistication leads to better outcomes.

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

#204

Post by bob1029 »

Kamq wrote: post #200
bob1029 wrote: post #198

Earlier quoted context omitted.

> When you hit that 1/10 product, you will experience some pain. There is a neat little trick I learned. Wait until leadership is under fire from customers and/or investors regarding the thing you thought might become an issue, and then present your solutions. Once you have proper buy-in, you can likely move way faster than by trying to constantly side-channel things through existing processes. Spinning hypothetical…

> Once you have proper buy-in, you can likely move way faster than by trying to constantly side-channel things through existing processes. I've noticed this as well. It's amazing how many road blocks an executive trying to save their reputation can clear for you.

> It's amazing how many road blocks an executive trying to save their reputation can clear for you.

Precisely. The grandmaster software engineer learns to manipulate organizational inertia, fear and egos in order to achieve their goals. Simply detecting when someone has their heels dug in on something will take you about 80% of the way there.

Showing up to the 5 alarm fire with a perfect solution that can be deployed within 48 hours will make you look infinitely better than if you engage a months-long headbutt session with your managers about potential fires. Prepare your magic in secret and reserve your hope. If you are right, it will pay out. Be patient.

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

#205

Post by gregmac »

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.

This is exactly my point. It's even worse in a "school test" situation, because who knows what contrived scenario the instructor has invented depending on what their focus is (eg: DNS vs physical net vs routing vs apache config).

Maybe there are multiple DNS servers for the zone that are returning different IPs, maybe one or both of them is even in split-zone configuration so it returns a different IP depending on if you're internal or external. Maybe the client has manual DNS configured or a hosts entry that's wrong.

Each of these problems would have several more layers of troubleshooting steps and branching, and it's not even a complete list -- and this is only if the problem is DNS-centric! There's hundreds of other branches for each of the other problem categories.

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

#206

Post by grecy »

flohofwoe wrote: post #103
goodpoint wrote: post #98

Earlier quoted context omitted.

Not at all. Software engineering is very much a thing and requires a different skillset than programming.

I suspect this may be a 'cultural' issue: For instance in Germany with its strong engineering tradition, nobody in their right mind would call somebody who builds software an 'engineer' (there are some google hits for "Softwareingeneur" but I bet this has a fairly recent thing and has been leaking back from English). A person who builds software is simply called a 'programmer' or 'developer' here. And I really have m…

I have a bachelor of software engineering, accredited by the Australian institute of engineers. Many of my university buddies studied computer science, so I saw the difference in course loads and expectations then, and 17 years later I’ve seen it play out long term.

If I have to pin it down, I’d say my degree had a lot of focus on all the phases of the SDLC, while computer science and programming are just one phase.

My course was an extra year and included mandatory classes on testing theory, large scale system design, real time systems, personal software process, and much more theory about the what, why and how of each phase of the SDLC.

My computer science friends were just writing code, without much education on the bigger picture.

So I would say a programmer is doing one piece of building a software system (like a bricklayer), while a software engineer keeps in mind and can actually perform all the tasks required to design, build, test, document and support the software (all the people required to build a building from conception to completion)

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

#207

Post by jasondigitized »

fatneckbeard wrote: post #140
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.…

money is not the goal. providing a useful and valuable product or service to customers is the goal.

Only if the problem is pervasive and people are paying money for it. Providing value just increases the probability that you will make money. You can have a very valuable service/product and fail miserably because you have no idea how to run a business and lack the know how and fuel to power awareness activities like marketing and sales.

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

#208

Post by gregmac »

josephg wrote: post #56
orderedtree wrote: post #7

Earlier quoted context omitted.

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…

Debugging works extremely well during an interview because:

1. Your evaluation can be interactive: you're watching them step through, can stop and ask questions about their thought process, etc. If it's a theoretical problem (ie: not on a live computer) you can even re-calibrate on-the-fly if they're really quick (maybe a lucky guess) at narrowing down the issue, or just asking "what if this happened instead, what would you do?"

2. Grading the candidate is subjective, just like the rest of the interview process.

The OP was talking in the context of college-style evaluation. I don't think you can apply either of these things to grading someone in a course. (1) doesn't scale, and (2) isn't a fair (or unbiased) way to evaluate students.

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

#209

Post by yamasanama »

randomdata wrote: post #202
yamasanama wrote: post #118

Earlier quoted context omitted.

> I'm not sure it can be removed, fundamentally. I've not had this for the last 10 years, so it can definitely be removed. Obviously everybody is welcome to bring up whatever is interesting nd worth discussing, and that's what we do in my current and previous workplaces. But there should not be a requirement that everybody has to bring up sth, which would lead to the described issues..

> I've not had this for the last 10 years, so it can definitely be removed. You’ve sat in regularly scheduled silence for the past 10 years and people still show up? > Obviously everybody is welcome to bring up whatever is interesting nd worth discussing But logically they would have already said it when it first became interesting, unless they felt pressure to pad a scheduled meeting with content, withholding inform…

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.

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

#210

Post by isityouyesitsme »

lazyasciiart wrote: post #77
quanticle wrote: post #71

Earlier quoted context omitted.

What if your job was open enough that you could find dozens of interesting fun things to code on the side? No job is that open. From your other comment in this thread: 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. I guess I'm fortunate in that I don't really have that many meetings or calls, and I don't hav…

> 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.
Post reply on HN