What every computer science major should know (2011)

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.

* Writing skills. It is absolutely important that developers be able to communicate needs and requirements with precision and specificity. I always recommend that developers spend more time with their QA staff as the experts next door. Good QA people are excellent, I am mean absolutely astounding, communicators with a very deep understanding of the product.

* Structure versus composition. So many developers really want the world to be simple AND easy. There appears to be some false expectation that programming is like putting lego pieces together, and when this isn't the reality they are utterly lost. Instead developers need to have beat into their heads that code is more like a thought structure. Part of this comes from developing reading/writing skills and part of it comes from an appreciation that logic and abstractions aren't static qualities.

* Reading code. I often see junior developers struggling with how to write code. This is the vast majority of programming related topics I see online. There is a lot of insecurity around this and many developers first try to solve for the insecurity opposed to actually writing original code. This means that instead of taking a risk on writing original code developers will cost themselves in comfort blankets of tools, frameworks, dependencies, and layers of configurations. These insecurities are better solved from building comfort directly through an appreciation of reading code (RTFC).

* Technology diversity. Most developers I have worked with either get into stuff like robotics, or IoT, or simply remain hopelessly isolated to writing code in their primary domain. Most developers who isolate themselves to the code have no idea what is really happening in technology whether its security, networking, hardware, storage, or whatever. The really sad part is that many developers falsely believe themselves to have some expertise or advanced understanding of these non-coding concepts when its very clear, to people in that line of work, the developers have almost no practical experience there (spinning their wheels). As an example I have seen numerous comments here on HN where developers will downvote, into oblivion, networking or security focused comments that defy common understanding of application coding despite never having touched a switch, router, or any sort of security vulnerability assessment/resolution.

* Product management. More often than not developers are writing code in support of some software product. I often see many developers in pursuit of qualities completely opposed to the desires of the end users or the business that pays the bills. Sometimes these erroneous intentions are due to pursuit of easy, sometimes its due to an imaginary understanding of what people want, and sometimes its due to a false or incomplete understanding of the technology. No matter the reason developer focused intentions are generally bad.

* Data structures. Not having a computer science background myself I have always imagined that data structures are a core component of a good CS education. I am frequently reminded of how wrong this thinking actually is.

---

I also see developers often spending amazing amounts of energy focused on qualities that aren't helpful to their careers or the products they support. The following is a wishlist of what many developers wished they learned from their education that simply isn't helpful.

* Frameworks. A framework is an application serving the purpose of architecture in a box. Sometimes a framework is abused because its either completely unnecessary or because a developer is using it to solve all of the world's problems. A framework isn't going to do your job for you or get you promoted. It is just a tool. Sometimes original code really is better.

* Testing. Test automation is important. A good set of tests reduce risks of regression and demonstrates appropriate handling of various features used in unexpected ways. Many developers often test for all the wrong things. Tests are tech debt. Tests are not an excuse to avoid reading code. When in doubt about what to test sit down and have a very precise conversation with your QA people.

* Design patterns. Memorizing patterns is never helpful and is sometimes harmful. Instead solve the problem any way possible, even if inefficiently. Then refactor that solution over time to achieve better performance and superior simplicity. Through that process of continuous improvement you will unexpectedly learn design patterns.

1)

The ability to communicate what needs to be done, and how it is to be done, _before_ diving into the work. I work with tons of people who, sure, can get the work done, but I have little to no visibility about what they're going to do and when they think it will be done. I'm never going to be in the code as deep as you -- the purpose of my management is to help make sure the thing you do fits into the rest of the plan and doesn't waste time and resources. What good does it do our team if I don't find out how long it was going to take until you finished?

Inability to do this is generally an indication that they've not done the task before, can't tell you how they're going to solve it before they actually do, or are generally unable to plan their work at a higher level that is useful for a manager. And I don't even mean that the answer has to be a rock-solid time estimate -- if they can raise and communicate the uncertainties, that already is an important piece of information and next level thinking -- what do you know you don't know.

You can tell a more experienced person by whether they can give you plans and estimates for how long and what approach they will take, before they immediately start the work. The work isn't just a coding puzzle to be solved -- they understand it's a project to be managed properly and are working at your level to plan it. Versus you having to painfully extract that info from them.

2)

The ability to self-assess whether their approach is the right/best approach, or what compromises or missing elements their approach adopts. Rarely do I find that people who dive right in because they "know how it needs to be done" are doing it because that is really the right way among all possible solutions. More like, it's the first thing that popped into their mind.

You can tell an experienced person by whether they take some time at the beginning to debate / discuss with you what approach optimizes for what outcome (whether time, resources, maintainability, scalability, data integrity, etc).

The person who does even these 2 things (or similar indicators of self-reflection and considering the problem) is -- almost unfortunately -- the standout these days.