When you have your best idea ever, always remember that the idea is just 1% of the journey Yes, ideas are cheap. At least in the world of software engineering and product development, everyone and their grandfather have ideas that may be great. The distance between the idea and the reality is great. Here’s Steve Jobs about ideas
When your project is late, never ADD people Most of the time this will slow you down. The reason is that with each additional person you add to a project you’ve created that many more paths of communication. If a project is late, adding people to it will make it later. See * The Mythical Man Month by Fred Brooks.
When planning your time, always allocate at least 20% to learning more Software engineering, programming languages, libraries, platforms, hardware and software are constantly changing. It take a real sustained effort to keep yourself up to date. What was a good or best practice a year ago may no longer be right.
When arguing about a design or a feature, always stop and go ask a user. Good products don’t come from debate around a table, they come from discussion with the actual users. Don’t guess, don’t argue, go ask! This is known as “getting out of the building”.
When planning a project, always work in short increments. Follow Agile practices, whatever your favorite flavor is, scrum, XP, Kanban, it doesn’t matter. Different teams and people like different approaches. And they change and evolve all the time. But there are eternal truths there. Work in small chunks. Even smaller. Even smaller. Don’t change many things at once because when your code invariably breaks, you won’t be able to tell why.
When you are spinning your wheels, always stop, think, and only then act. Google It! The amount of knowledge and down and dirty solutions that you can find on google is infinite. See a strange error message? Google it! And learn how to edit the error message, removing the parts that are specific to you so that you get matches. Or ask on the right forum or mailing list. You need to learn how to ask a question in a way that it will be answered. Make it as easy as possible on the answerer.
When coding, never go beyond the immediate requirement. Write only the code you need to solve the problem RIGHT now. You might think that this class clearly will need all this methods even though no one is calling them yet. This almost never works out. Don’t spend time to set things up for what you’ll need in a month. You’re usually wrong.
When coding, always wait to optimize until later. Optimizing too early is one of the cardinal sins of programming. You never know where the bottleneck will be, The thing you think will be slow, will be fast, and vice-versa. Actually you might end up ripping it out anyway!
Conversely, when coding always keep a list of ‘technical debt’ items These are coding chores, cleanups, fill ins, removal of dead wood, that you purposely put off, even though you know you will have to come back to them. Later, when you want a change of pace in your coding, you can look at that list for some easy pickings!
When your program blows up always stop and read the error messages. Catch yourself jumpint to conclusions or seeing what’s not there. Fight the impulse that you know what must have failed. Often the right answer is right there in the error message. It might be buried in the middle of a lot of noisy trace output, but discipline yourself to actually read it.
When programming always use a source control system. It’s your safety net. This is especially true when working with other programmers. Learn your SCS tool so you are never reluctant to use it.
When designing software, always keep concerns as separate as possible. Design for loose coupling. Pay attention to the Single Responsibility principle. Whether it’s a single class or function, a subsystem or module, or a whole system, minimize dependencies. Learn about dependency injection and other techniques for decoupling.
When doing object oriented programming always avoid using class inheritence While tempting, it is almost always better to avoid using inheritence in your class design. It brings undesireable coupling with little benefit that could be had in a simpler way.
When programming always use ‘intention revealing names’ Chosing the right names for classes, variables, methods is one of the best ways to ‘document’ your code. Follow your language’s naming conventions closely and then create names that reveal your intention. Name things after what they do, not after how they work! Also make sure names are internally consistent. (Ref: Intention Revealing Names)
When programming, always comment your code, but not too much. The exact line is a matter of (fervent) debate but it is almost universally accepted that having no comments is a bad idea and that its easy to have too many comments. Keep your comments at the start of each source file, and at the start of each method. Occasionally you might want to put a few lines of comments inline. But that desire often alerts you to a refactoring opportunity.
Many of these are from books, blogs and my own experience. I will list all the credits that I can identify but I think in some cases these rules are so deeply embedded that I cannot recall where I got them from. If you see sonething that you think you came up with, I appologize!