Code Complete
It does follow. If you're hiring people who are equally attractive to you, and one is attractive in part because of the degree, then for them to be equally attractive they must be worse on your other desired qualifications - such as demonstrated competence. My claim is that demonstrated competence is more important than the degree. Therefore of those two candidates, the one without the degree usually turns out to be better. This is actually true about any discriminated against group (which people without degrees are). On average the discriminated against group may be worse (for whatever…
There is a fundamental point here that really bears thinking about. Software design has as a fundamental problem being able to express yourself in a way that is clear and remains clear as things change. Basic principles of good software design, like reducing cohesion, remain good principles no matter what "paradigm" you think you're using. When you change paradigms, be aware that the basic principles remain the same no matter what label you give them. And since design is all about tradeoffs, if you are going to have to violate a principle, you might as well do it in the clearest and most…
> This coding style is standard practice for Win32 API development. Do you have a public style guide that indicates this? I worked at Microsoft, and while there are teams that (very unfortunately) went with this "diamond" style of error handling, code written in the CNF (Cutler Normal Form) style, such as the kernel code, use gotos and a central cleanup point at the end of the function, which is also the same style used by the Linux kernel: https://github.com/torvalds/linux/blob/master/Documentation/... The "diamond" style hinders readability, especially when you have many levels of…
Code Complete 2 is kinda the bible on disciplined software engineering practice. That's a good start. Other than that - there is not that much theoretical basis. The core principle is that software engineering is about dealing with a situation where you have far too many variables to fit into a single persons working memory, and how to organize a group of people in a way that they can co-operate without turning the thing into a mess, really fast. It's more about having a set of understood processes, rather than what those processes really are, so that people can communicate about and…
I have hired some PhDs in your situation and worked with others, I personally just went to work after I got my BSEE. My observation is that you're halfway there when you realize that you need to improve, of the folks I saw who did poorly it was because they didn't realize that you could be both the smartest person in the room and the least capable at the same time. Right now, on your first job experience, even a kid who never went to college is better at programming than you are because they've been experiencing all the pitfalls that can happen and have built up a knowledge from that which…
I think Code Complete deserves its usual top spot on these lists. You need to understand the skill set of the typical entry level coder, even after acquiring a CS degree. There is so very, very much they don't know and Code Complete helps fill in a lot of the gaps. Most usefully it helps instill the idea that it's important to use practices that are backed up by evidence and that there is a lot more to learn when you get out of school. A lot of the advice in it may seem a little outdated or even trivial to a lot of developers, but it is not less fundamental. Being inculcated in the ideas that…
I agree with the other poster saying that learning programming languages doesn’t make you a better coder, just as learning natural languages doesn’t make you a better communicator. It’s much more efficient to pick a flexible programming language which allows using various concepts (functional, OO, etc) and constructs and then apply it in various domains which exercise those concepts/constructs. Coding can also be learned. Code complete (2nd) is one of the few books focusing on this area - the author calls it construction - and goes into detail about building functions, parameter passing and…
The first of your two objections is perhaps a confusion of the word best practice. It doesn't mean ultimatum as much as it means something seriously worth considering. What constitutes "one thing" is a judgment call, and it varies tremendously as should be evident from all the other replies here trying to define it concretely. I imagine the definition changes a lot depending on how one's catalog of discrete things change. The point is not to define this "one thing" for you, it is to get you thinking about it. A lot of the best practices that have been put forth are the empirical outcome of…
This was how I got started in the industry. I won't center this on myself, but I'd give you this advice... Start building shit. Build anything. Build games, build websites, build console apps that compute large sums of numbers. Make yourself code daily, and commit to micro-projects, even if you never list them on your portfolio. Try to focus on learning one strong object-oriented language and then one strong functional language. Learn to appreciate both styles for what they are without being dogmatic about one or the other. Don't just memorize design patterns, build mini-apps that…
1. All programmers should drop the "I don't have to be good at math" habit...you're disrespecting people who are likely in possession of knowledge that will help you later. Being "good at math" means you communicate and try to understand concepts. It's more about attitude than knowledge. 2. All programmers should learn Galois theory, not only to get over the idea that they can't be good at math, but to learn to appreciate math. The book by Ian Stewart is good, although I would supplement it with Artin or Dummit and Foote. 3. Try to figure out why Ken Thompson and Dennis Ritchie did what…