Rules for Software Engineers
If your job title includes “software engineer”, here’re some rules you should follow
Note: This post wasn’t published till 3rd February, 2024 because I lost interest in it. It eventually got published (at the older date) because I didn’t want to just discard them. But it hasn’t been updated or completed.
Solve problems
Find problems. Solve them. That’s all you have to do in any job anywhere.
Develop a problem solving mindset.
Frame everything as a problem. Look for solution. Solve it.
When the solution includes problems, treat each of them as independent problems, and solve them. Then solve the original problem.
Break down a problem into smaller problems. Solve them.
If you can find a solution that will solve multiple problems, solve them using that solution.
Identify problems. Solve them.
That is the mindset for success.
Solve real problems
While some people have a problem in adopting the problem solving mindset, some others have a problem where they focus on the wrong problems or, even worse, unreal problems.
Let the real world (business) be the guide on which problems to be solved.
Prioritize the problems that are the most impactful when solved.
Let your common sense and discussion with others in the team guide you in prioritization.
Actually solve problems
Do not call a problem solved until you solve it.
What this means in coding is that you need to test your code. Either manually, or through automated tests.
At project level, the rule of actually solving problems will guide architectural design. A software design that solves the wrong problem will lead to suboptimal outcomes.
In organizational terms, this means that things aren’t