15 Things That Every Software Engineer Should Know 🧑💻
A Software Engineer is a person who applies the principles of software engineering to design, develop, maintain, test, and evaluate computer software.
The term programmer is sometimes used as a synonym, but may also lack connotations of engineering education or skills
- In a Software Engineering organization, we need to be more concerned about scale and efficiency, both for the software we produce as well as for the organization that is producing it
- As Software Engineers, we are asked to make more complex decisions with higher-stakes outcomes, often based on imprecise estimates of time and growth.
- “Software engineering is programming integrated over time.” Programming is certainly a significant part of software engineering: after all, programming is how you generate new software in the first place.
Cubes aren’t squares, distance isn’t velocity. Software engineering isn’t programming.
4. This distinction is at the core of what we call sustainability for software. Your project is sustainable if, for the expected life span of your software
5. This suggests the difference between software engineering and programming is one of both time and people. Team collaboration presents new problems, but also provides more potential to produce valuable systems than any single programmer could
6.We can also say that software engineering is different from programming in terms of the complexity of decisions that need to be made and their stakes.
7. The job of a software engineer, or a software engineering leader, is to aim for sustainability and management of the scaling costs for the organization, the product, and the development workflow
8.A serial startup developer could very reasonably have 10 years of development experience and little or no experience maintaining any piece of software expected to exist for longer than a year or two
9.For any project that didn’t plan for upgrades from the start, that transition is likely very painful for three reasons, each of which compounds the others:
You’re performing a task that hasn’t yet been done for this project; more hidden assumptions have been baked-in.
The engineers trying to do the upgrade are less likely to have experience in this sort of task.
The size of the upgrade is often larger than usual, doing several years’ worth of upgrades at once instead of a more incremental upgrade.
10.There is a factor of at least 100,000 times between the life spans of short-lived code and long-lived code. It is silly to assume that the same best practices apply universally on both ends of that spectrum
11.Hyrum’s Law: with a sufficient number of users of an API, it does not matter what you promise in the contract: all observable behaviors of your system will be depended on by somebody
12.We should be able to explain our work when deciding between the general costs for two engineering options
What do we mean by cost?
We are not only talking about dollars here. “Cost” roughly translates to effort and can involve any or all of these factors:
Financial costs (e.g., money)
Resource costs (e.g., CPU time)
Personnel costs (e.g., engineering effort)
Transaction costs (e.g., what does it cost to take action?)
Opportunity costs (e.g., what does it cost to “not” take action?)
Societal costs (e.g., what impact will this choice have on society at large?)
13.Acknowledge the amount of time that you and your team spend communicating and in interpersonal conflict. A small investment in understanding personalities and working styles of yourself and others can go a long way toward improving productivity.
14. If you want to work effectively with a team or a large organization, be aware of your preferred working style and that of others
Start small: ask questions and write things down.
15. Make it easy for people to get the help they need from both human experts and documented references
