- Programming is 99% self-taught. See all that stuff you learnt in that Java class? Yeah, you’re going to relearn it all when working on a real project.
- Given time everything can be hacked/exploited. Regardless of how secure you think your code, or system, is.
- The first 95 percent of your solution will take as long as the last 5 percent.
- If the documentation or design is easy to write down then why not do so? If it is difficult to write down you darn well better do so.
- You can’t automate or program what you can’t do manually.
- There’s no such thing as a simple bug. A stupid mistake like leaving out a semi-colon or misspelling a variable name can easily take a week to find and fix and can cause significant loss of sleep.
- The more code you write the more you shut up about what’s possible and what’s next to impossible. And the more you pity those newbies with that “Of course it’s possible!” mentality.
- The language you use doesn’t matter. There’s so much fuss about which language is better for x or y. At the end of the day what matters is can you solve the problem? As a company manager, I’ll want to see a running system. Not a running (insert language name here) system.
- Six months later, you wouldn’t recognise your own code. Documentation and commenting are more of a survival tactic than niceness to whoever encounters it next.
- Programming isn’t sexy at all. Try taking that girl home by telling her your heroic tale of saving an entire department by rewriting a recursive function to take advantage of a feature in the new server Intel chips to scale up their online orders. Then tell me how it goes.
- Programming can be addictive. I can’t go through an app or a game or a site without mentally visualising what that code must look like. I don’t know if I’m alone on this one.
- Programming is tons of fun. But the fun only begins once you “get it”.
- Software development is crystallizing knowledge and making it executable. The reason why software projects run over budget is that we don’t know which things we don’t know when we write the schedule. Scheduling is predicting the future, something which is formally impossible.
- Notwithstanding the preceding point, we could estimate software schedules to within a few per cent. Companies already know how to do this. They have to project financial budgets out a year or more. They hire a dedicated staff of professionals to do the budget, and to monitor budget variances on an ongoing basis. The chief of these specialists is a C-suite director who reports directly the the CEO. An external agency audits the work of these specialists every year, and it’s a Big Deal if the auditors find anything. Managers are directly responsible to make their budget and production numbers, and there are actual negative consequences if they miss. Now, compare that to how software is scheduled, as a side project by developers who are not specially trained, with no management visibility and no feedback. No wonder software is late.
- A disciplined, professional software development team with a good leader is incredibly productive. We know how to develop software efficiently. We just don’t do it. We don’t do things we know we ought to do because they are difficult, because we are lazy, and because our managers let us be lazy. We allow ourselves to believe we don’t have tome for testing, documentation, etc. We obsess over the 10x programmer, when what’s really more important is the 10x manager, because he can make half-a-dozen programmers more productive all at once, or hold them all back at once.
- What operating system your code runs on matters not at all. What language it’s coded in matters a little, but there are generally several excellent choices. Where you put the curly braces is not important, as long as the whole team does the same, and there is a tool that will automatically reformat your code if needed. What matters is the team, the people, and how well they work together. Arguing about O/S is dumb. Arguing about language is dumb. Arguing about curly braces is, … oh god it’s so wasteful. Argue about what matters: how to work together, how to have a common understanding of the problem.
Lastly One of the great truths of programming is that there are no great truths of programming.