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.

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

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.

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

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.

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.

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.

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

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.

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

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.

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

People seem to forget we're all humans.