I recently watched a talk by @mike_acton who’s a lead programmer at Unity. In his talk ,provocatively titled “Everyone Watching This Is Fired: Tips for Game Industry Programmers”, he talked about the things a programmer should be able to do in order to be considered a good programmer.
On solving problems
Be able to articulate problems you’re trying to solve precisely.
Articulate the problem you’re trying to solve precisely. You must be able to say it. Out loud.
Someone else can articulate the problem you’re trying to solve.
Articulate why the problem is important to solve.
Articulate how much is worth solving.
Articulate why the problem is worth solving.
Articulate the steps required to solve the current problem
Have a plan B in case your solution doesn’t work
Implemented your plan B first before your plan A.
Articulate the unknowns and risks associated with the current problem. Estimates
Articulate the test for completion for the problem. How do you know when you’re done.
Articulate the hypothesis related to your problem. Find out how you can prove that your hypothesis is wrong.
On time management
If you think you can “make up the time”, you’re wrong.
Write frameworks and tools that you can use multiple times to solve problems. Verify that it has value.
Schedule your time well. Know what you’re gonna do with your time
On working with a team
Articulate the latency requirements for your current problem. How long until someone needs the problem to be fixed.
Articulate the throughput requirements for the problem. How much do you need to test the requirements of the problem.
Articulate the most common concrete use case of the system being developed. Develop the API for all of those usecase
Be vigilant about not wasting other people’s time. The other side of the coin is also through. The If asking your team can save you weeks of development, then you should know when to ask your team.
Actively work to bring value to the people you work with.
Actively work to ensure underrepresented voices are heard.
On writing code
Know the most common real-life values of the data being transformed.
know the acceptable ranges of the values of all the data being transformed.
Articulate what will happen when data outside of the range enters the system. Does it crash? Does it display an error message? Don’t hope that it will never happen.
Articulate a list of input data into the system roughly sorted by likelihood.
Know the frequency of change of the actual real-life values of the data being transformed.
Profile the performance of your system frequently.
Profile memory usage of your system frequently.
Use multiple different profiling methods to measure the performance of the system. FPS is not a measure of performance. Measure process time.
Articulate how to significantly improve the performance of the system without changing the input/output interface of the system.
Know where the data comes from.
Know how often you read data that is not needed as part of the solution. Know how much you’re wasting.
Know what data you’re writing. Know where it’s used. Organize it.
Know how often you write data you do not need as part of your solution.
Articulate how all the data is laid out in memory
Know specifically how to debug live release builds of your work when they fail.
On working with technologies
Read (at least partially) the available documentation for the hardware, platform, and tools you use commonly.
On designing things
Actually sit down and watch the actual use of the system you’re working on.
Know the slowest part of the users of the system’s workflow with high confidence
Know what information users of the system will need to make effective use of the solution.
Articulate the finite set of hardware I am designing the solution to work for. Know you’re supported hardware.
Articulate how the set of hardware specifically affects the design of the system.
Never use the phrase platform independent. No such thing. There’s no such thing as future proof
On growth
Actively seek constructive feedback and also take action on the feedback
Don’t actively avoid the uncomfortable (professional) conversations
Don’t actively avoid any professional conflict.
Consistently interact with. Other professionals, professionally.
Articulate what others should expect from you.
Be someone who doesnt require multiple reminders to respond to a request or complete work.
Pursue opportunities to return value to the commons.
Gab De Jesus 