Notes: Minimum bar for software engineering

2022-10-13

From the video Everybody watching this is fired, by Mike Acton on abilities he believes software engineers should have as a minimum bar.

Can articulate precisely what problem you are trying to solve.

You should be absolutely clear on what the specific problem you're solving is.
Can articulate precisely to your team what problem you are trying to solve.

Say clearly what the problem is out loud to your team mates.
Can confirm that someone else can articulate what problem you are trying to solve.

Ensure other team members are definitely clear and understand the problem you are solving.
Can articulate why your problem is important to solve.

Be clear on the value added by solving the problem.
Can articulate how much your problem is worth solving.

Be clear on how much time and effort the problem is worth. As long as it takes isn't a valid answer. Could be a year, six months, two weeks. Put a time on it.
Have a Plan B in case the current approach doesn't work.

You can never be sure if Plan A will work as expected, always have a Plan B.
Implemented your Plan B in case the current approach doesn't work.

Plan B is a safety net, implement it so the team can be confident that Plan B will work. You might realise Plan B is enough to get the job done.
Can articulate the steps required to solve your current problem.

Clearly understand the steps required, otherwise you're lost. Take the time to figure out those steps.
Can clearly articulate unknowns and risk associated with your problem.

You can't give a reasonable estimate unless you know something clearly. Note down known unknowns and work on making them known.
Never attempt to "Just make up the time" without immediately talking to someone first.

Flag with your team mates or manager as soon as something else interrupts you, or shifts your attention off your current problem.
When writing a framework or utility you have used it multiple times to solve the same problem.

Verify that your framework or utility solves the problem it was built for.
Can articulate the test for completion of your problem.

You should know when your problem is solved, or when to stop. How much faster should it be? How much smaller should it be? Understand when its done.
Can articulate the hypothesis and how it could be proven false.

The scientific method focuses on proving something wrong.
Can articulate the latency requirements for your current problem.

Understand how long it should take the thing you're building to run. What are the limits you need to work within?
Can articulate the throughput requirements for your current problem.

Understand how much data the thing you're building should pump through it. One thing? Ten things? One thousand things?
Can articulate the most common concrete use case of the system you are developing.

Understand the most common thing your system will have to do.
Understand the most common real-world values of data you are transforming.

Know what the data looks like coming in, understand its shape.
Understand the acceptable ranges of data you are transforming.

Know the entire range of data you are dealing with.
Can articulate what will happen when data outside that range enters the system.

Know what your system will do when data it doesn't expect is passed in. Should it crash? Should it log an error and continue?
Can articulate a list of input data into your system based on its likelihood.

What's the most likely structure? Build for that first, then what's the next most likely?
Understand the real-world frequency of change of the values you are transforming.

If something in reality only has to change once a second, don't calculate it every frame.
Have read and understood the documentation for hardware, platform, tools you commonly use.

Read the manual.
Have watched the actual users of your system.

Unless you've watched someone use your system you can only guess.
Understand the slow part of the workflow.

Deeply understand the workflow and the slowest parts of that workflow. If running tests is the slowest part of the workflow, focus on making that part faster.
Understand what information users of your system will need to use it effectively.

Ensure your users have all the information they require to get the job done.
Can articulate the finite set of hardware you build your solution for.

There will always be a finite set of hardware/devices you target, state what they are.
Can articulate how that set of hardware specifically effects the design of your system.

The hardware/devices you target will effect the way your system is designed. e.g large screens, small screens, slow networks, etc. Otherwise you are blindly developing in an ether.
Have profiled the performance of your system recently.

You should understand how your system performs. This should happen often not just once or never.
Have profiled the memory usage of your system recently.

You should understand how much memory your system uses. This should happen often not just once or never. Otherwise how do you know you don't leak memory?
Have used multiple methods to profile your system.

Measure using proper units of measurement, e.g time in seconds or milliseconds. Measured in multiple ways.
Understand how to improve the performance of your system without changing its input/output interface.

You should understand steps that can be taken to improve your system performance. Understand when you've painted yourself into a corner.
Understand how to debug your production build/system when it fails.

Developer mode / debugger tool is not an answer, you should understand how to debug your production system when you don't have the aid of an IDE or a specific tool.
Understand what data you are reading and where it comes from.

Can your system be made parallel? If you have to wait for data first then it can't. Understanding where the data comes from lets you understand what is possible.
Understand how often you read data you don't need.

Know how much data you are wasting. It may be due to a tradeoff but understand why.
Understand what data you are writing and where it is used.

Who uses this data? When is it used? How is it used? What latency requirements does it have?
Understand how often you are writing data that is not needed.

How often are you writing the same thing? Can you optimise it?
Articulate how all the data is laid out in memory.

Understanding this allows your software to run consistently, with more reliable performance measurements.
Never use the phrase platform independant.

There is no such thing as being truly platform independant. Your software runs on some kind/range of Hardware. Building to a spec/standard is a different thing.
Never use the phrase future proof.

It is impossible to reason about future problems.
Schedule your time well.

As an adult, organise your time.
Be vigialant about not waiting others time.

Don't immediatly interrupt team members when Google can help. Similarly if you are stuck for a while ask others on your team.
Seek constructive feedback and take it seriously.

Have a way to ask for feedback, and actually do something about the feedback.
Do not avoid uncomfortable professional conversations.

If you see a problem with the system, tell others about it.
Do not avoid professional conflicts.

If two people aren't talking when they should be, say so, maybe help?
Interact with other professionals professionally.

Do not yell, remain calm and collected.
Articulate what others can expect from you.

Tell others what you can do for them.
Do not require multiple reminders to respond to a request or complete work.

Don't ignore people, you shouldn't require several reminders to get back to people.
Return value to the commons.

Share things to boost everyones skills.
Actively work to bring value to the people I work with.

You work on a team, be a team player.
Actively work to ensure under-represented voices are heard.

Do something to ensure minorities are heard. e.g ensuring your website is accessible.