Hacker News Reader

This is a great list. I would add estimating, although it's implied in a few of your points.

As an engineering manager I find that a consistent difference between good engineers and great engineers is that great engineers can tell me how long something will take even when they haven't done something just like it before. That doesn't mean they can perfectly forecast how the hours will be spent -- no one could do that -- but they know how to figure things out, know how to build in some buffer, and know how to go heads down and crank when absolutely necessary, and as a result they can consistently hit deadlines.

Don't you think estimation is a management job? What if Engineer decides to over estimate and enjoy the freetime?

Usually it's a team effort and not just one person. Yes the manager should have say.

A manager with an attitude that engineers would pad their estimates to "enjoy the free time" is a guaranteed way to get good engineers to quit a team. Not only does it betray a complete lack of trust, but it means engineers are going to be pressured to lower their estimates, which never turns out well.

Absolutely not. It's hard enough for a seasoned senior engineer to estimate something, let alone a non-technical manager. (Of course, said seasoned engineer might be in a managerial role now but it's still an engineering task.)

Only the person who does the job can do the estimate. Estimation by third-party is no better than rolling a dice.

I think the concepts I would add are understanding the differences between an estimate, a commitment, a plan and what role risk plays in all of these.

Providing an estimate isnt impossibly hard, I've found there is much more forgiveness for putting a long estimate in, and then coming in early, than putting a short one in, and coming in late.

Stuff I've not done before can be a real challenge, I just add a 50% slop factor, but I won't even give a guess until I can at least have a modicum of understanding of the complexity of the problem, technologies and people involved.

Generally for stuff I'm familiar with - I take how long I think its going to take, then double it, and thats what I give to my management. For stuff I'm not familiar with, I guess based on like-like work, and then add 30-50% more time in, then double that. For some of our customers however, working with them incurs a time penalty, so I add another 20-40% on top to their estimates.

The feedback I've been given is that my time scopings are reasonably accurate however. So while I feel silly turning in an estimate for 24 hours for a task that I think ought to take 8, time and time again, it takes closer to 18-20 hours rather than the 8 I feel it ought to (usually because of external factors outside of my control).

It’s funny that in your narrative good to great means scoring well on the one metric that helps you personally.

I’m not picking on you. But I guess it highlights how hard this list is.

Estimation would by no means be the distinguishing factor to call a programmer great in my book

Estimation effectiveness is inversely proportional to the intrinsic difficulty of the problem you work on. Being a programmer who is good at estimation is a bit like being a doctor with the lowest post-op death rates - it doesn't necessarily mean you're actually the best.

Well, I don’t think it’s just about what helps me. I think it’s about the craft of Engineering, which is fundamentally about shipping things.

You can be a good coder but struggle to deliver because you get distracted or rabbit hole, over or under engineer, etc.

The engineers who have really mastered their craft have mastered not just the coding, the infra, operations, etc. they’ve mastered putting it all together and getting it out to the world.

The ones who have mastered all that can usually give pretty good estimates. The ones who haven’t usually find estimating to be difficult.

So it’s not so much that estimating is the single critical skill, but rather that estimating comes from a synthesis of all the other skills, and as a result it’s a good indicator for how much someone has mastered the craft.

> 10) understand that “good enough” sometimes is all you need (still try to fix it later :) )

This is something most CS grads don't really grasp immediately, but in the real World business and time constraints normally trump perfection.

Technical debt is fine as long as it's fully understood and managed properly.

"Good enough" is a risky goal when not everybody shares your sense of what that is.

Early in my career good enough meant it worked correctly with no thought put into how that functionality is going to age.

I would do things like find a function that did most of what I need, add a bool parameter to trigger a new mode (usually giving it a default value), add some comments, commit, ship! Ten years later that function has four more mode parameters and it's a mess.

These days I'm better at doing one more pass to break things apart or change the interface to accommodate new functionality. I also try to never have bool parameters that triggers a different mode and almost never give parameters default values.

Most of these are in the article. The author mentions:

1) both http and ssh

2) source control and team work (and suggests courses built around these)

3) multiple sections on problem solving and algorithms (incl. proof techniquese, formal methods, knowledge of data structures and algorithms)

4) nothing in particular

5) nothing in particular

6) covers communication skills

7) emphasizes each student taking a lead role on a team in suggested team-based classes

8) not explicit

9) suggests writing and being graded on tests throughout educational career

10) section on graphics and simulation emphasizes this.

Yes, but the author mentions a lot of other stuff - I think the OP of this comment was just trying to trim out some superfluous topics.

Who is to say that a particular topic is superfluous though - I did a maths heavy CS degree and that has helped a lot with subsequent work in engineering and finance.

Because the article's title specifically states that every CS major should know those topics. Should every CS major know formal methods, AI, robotics... ?

Yes the heavy math you took was very helpful (and I personally agree as someone who did a CS heavy math degree), however as stated above the list should really be a minimum requirement. Anything extra is superfluous.

GP of comment says:

> I learned most of the topics mentioned in this document while in school, and although they are all valid, they are not enough for real world needs.

Emphasis is mine. I do not know how to interpret the emphasized part except as an indication that GP thinks OP skipped the listed topics. I was simply pointing out the overlap between GP's additions and OP's original list.

I have a peculiar question, has it ever happened to get stuck in a task and not being able to solve it ? what do you do ? if it's an optional feature, I guess you can always write it down but if it's critical ?

Ask for help. Keep trying different approaches. Ultimately, decide how important it is to solve the problem and if it's going to cost more than it's worth, then give up and do something else.

11) Learn proper research skills so you can continually be finding better solutions to problems encountered in your work/projects.

> 4) design patterns (learn as many as you can)

Sure, learn them, but make sure you don't apply them blindly. Let the problem/solution lead you to familiar designs, not the other way around. I have seen some truly hideous code done in the name of cargo-culting "design patterns".

This is why I actually prefer it if people don't learn them. Where people apply them directly I've seen them misused more often than not and where they were used correctly, more often that not they emerged naturally without anybody ever really thinking "hey, we should use [design pattern] here".

Another bonus of that is that the user wouldn't be tempted to, for example, use the word "factory" in method/class names, which bugs the hell out of me.

I think I've been asked to implement singleton in python in at least three interviews and when I pointed out that a module was a natural singleton and that you didn't really need to "implement" it per se, I got blank stares each time. Sometimes no knowledge is better than learning by the book.

> 3) problem solving - how to breakdown problems, and how to overcome them when you reach a wall (use known algorithms when possible)

> 6) communication skills

I would argue these are the only two things in your list that should be included in a Computer Science degree.

There's a limited amount of time to cram everything into a CS degree, and it should focus on the science, not the practice. The science is harder to learn than the practice. All of the practice items are picked up on your first job out of college.

100% agreed! Communication is 80% of the job usually. So sad to see a lot of technical people who cannot communicate well!

People seem to forget we're all humans.

Thank you. I've made it to moderate success as a "software engineer" with your mentioned/trimmed list of topics, even without taking physics all the way up to electromagnetism.