Day 1 — Makers Academy
on learning to be less dickish and writing for people to read
Today was my first day of the Makers Academy coding bootcamp.
In order to keep track of my progress and try to remember this time in my life I’m going to write a short blog every single day of the course. I’ve done the 750words challenge for two months before so I’m hoping it’ll be manageable.
The two things that had the biggest impact on me from today, our ‘orientation’ day were around what Makers is there to do and about writing code.
I can teach anyone to code, I can’t teach someone not to be a dick.
This wonderful quote was attributed to one of Makers hiring partners. This makes so much sense to me and gave me a better understanding of what Makers is trying to do. We all have dickish tendencies, especially when in stressful high-pressure enviroments and everything in Makers seems to be there to help us manage these tendencies. Meditation, yoga, non-violent communication, all these will help.
When I think of my former company we had a long involved performance review system. In it you had to give feedback about your colleagues calling out examples of their strengths and areas of development. As a manager it was very hard to use this data as it was so subjective and anecdotal. I always thought a better question would be “Would I want to work with this person on a project?” Yes or No. Too many Nos for someone and you got there was an issue. Getting on with your colleagues was about the most important thing I’ve had in terms of job satisfaction and having successful projects and I’m excited to learn a lot about how to do that better.
The second one was something I took from Ben one of our coaches
You are writing your code to be read by other humans.
Its pretty easy to learn the syntax and general concepts and get the computer to do what you want it to do. And there is great pleasure to be able to do that. However your code needs to be easily understood by your other developers. Whether people on your team, or contributing to an open source project everything you create should be easy to work with, and hence super easy to understand.
Use meaningful variable names.
I sank down in my seat when I thought of all the
x.each {|a,b| i += (a+b)} type code I’d been writing.
The reason I was extra embarrassed is this is exactly the thing I fought everyone to do in my previous life as an Instructional Designer. When we work in PowerPoint we built a lot of our own basic graphics and hyperlinks in the slide. I pushed hard for everything on the slide to have a name in the Selection Pane so it was easy to find. And yet this best practice I fought so hard for in my previous life I didn’t relate across to coding.
This recognition brought me a lot of hope though. There have been lots of things popping up already that I can relate directly back to my previous work and this will help me make the learning meaningful. I’ll try to include these whenever possible in this blog.
When asked about when we are just using variables for trivial reasons Ben stated that if something was trivial it doesn’t belong in your code.
I finished the day by doing some yoga.
Note to self: do more yoga. it always works.
disclaimer: I’m going to be writing these on my commute to Makers each morning so typos etc may well happen. If you have big problem with that or enjoy good grammar probably my posts are not for you. That’s okay though. Don’t be sad or angry about it. Give someone you love a hug instead.
