Welcome to the Art of Computer Programming. I am Per Lundholm and ArtComputer is my company. I am a member of Crisp, a world known brand within agile development. I have been doing programming for over 35 years and here is what I have come to believe on the subject.
I will speak about craftsmanship, architecture and people. I will speak about Readability, Refactoring, Retrospectives, Resources, Responsibility, Respect.
If you wonder about the clock, it is written using my current passion, the Elm language. If you click on it, you get a full size version.
Programming is a craft. We do not create the same piece of software over and over again. Each time we solve a new problem. We like to look at well crafted code but we have different opinions on what "well crafted" means.
The first thing about craftsmanship is refactoring. Code is never well written on first attempt. We simply can not just sit down and type well crafted code from scratch. If we could, we would not be solving anything complicated. Instead, we learn about the problem as we go. Therefore, to create well crafted code, you need to refactor it. You can not simply stop because you got it working.
When you refactor, you change the code without changing its behaviour. To guarantee that, you need to have tests that will tell you when your changes break the code. Tests shall also be well crafted, of course. Serving as a specification, they should not be coupled to the implementation.
When your code pass the tests, you can start looking at readability. Never be proud of being able to read cryptic code, be proud of writing code that reads like running water. I have written 7 rules on code readability which you may enjoy but there are more sources out there.
Once the code is readable, you can refactor it further to become minimal. But never on the expense of loosing its readability.
As a professional programmer, you are obliged to take responsibility for your actions. Bad code can kill people or loose large amounts of money.
You should always treat other programmers with respect, you have no idea what their background is. Criticise behaviour or code but never a person. When you thinks something is not right, speak out of consequences. Eg "Unless we have tests, changing things such as a new version of a framework that we use, may break our code without us knowing it."
You should always respect the users of your software. If they can't use your system, it is a bug.
User respect is about understanding their situation when they use your system. Their mental model of the system is most probably different from yours. That is one reasons your naming of things must be constantly updated to stay in sync with your users' world. Mind the gap, if you see what I mean.
Your software is connected to how its owning organisation communicates, it is Conway's law. Amusing observation at first, but then you realise how painful it can be. It actually tells you that you can not redesign your system architecture without changing the organisation, and vice versa. Once you have established a working system, you have a hard time to innovate. Perhaps that is why Apple changed on how we look at mobile phones and Tesla changed the car industry. Neither were established and stuck with that law.
For us doing software, it is a problem when projects cross several systems because we need a little something changed in each of those systems. It is today called "component teams" as they are organised according to components, strictly following the system architecture. Thus a project will engage a lot of people which means a lot of communication and synchronization. Expensive and error-prone.
This is without doubt a large subject. It is also debatable what it really is. But let give you this, all systems have structures of different kinds, such as how data flows and nodes. These structures affect the system's qualities, such as security and performance. If you search the internet, you'll find many sets of qualities to look for. Let me give you one set by the acronym STAMPUS.
STAMPUS stands for Security, Testability, Availability, Modifiability, Performance, Usability and Scalability. What you might observe is that many ends with "-ility", which makes many speak of "ilities" as qualities.
You can read my blog post on why do we never get the time to work on system architecture to find short explanations on these attributes.