How can a bunch of philosophers who lived over 2000 years ago help you become a better software developer? The ancient philosophy of Stoicism has tools that can help you become happier and more productive.
This post is the first part in a series where we’ll explore different techniques from Stoic philosophy and how to use them to become a better software developer.
Zeno of Citium founded Stoicism around 300 B.C. in Greece. The school continued through the Roman emperor Marcus Aurelius in 180 A.D. The Stoic philosophers came from a variety of backgrounds. Some Stoics, like Marcus Aurelius or Seneca, were important and powerful, while others, like Epictetus were slaves.
The modern usage of the word “stoic” would make you believe that Stoicism is about being a melancholy robot. This is not the case. The primary goal of Stoic philosophy is to focus only on the things you control. The Stoics used reason to temper negative emotions. The Stoics worked to achieve a peaceful state of mind, regardless of adversity. They found happiness and peace in a chaotic world.
To achieve this peace of mind, the stoics developed a set of mental tools. These tools can be used to deal with chaotic situations, like those encountered by software developers.
Stoicism is useful because software development is an emotional and chaotic field.
Most of these situations occur because we get too emotional over things that are not in our control. Studying stocism won’t make these issues go away, but it will make it much easier to deal with them.
Ever want to give a tech talk to your peers? I recently built and delivered my first tech talk and I’d like to share my experience.
There are several factors that have contributed to my desire to to make a tech talk. The first is that one of my career goals is to become more involved with my local developer community. I am fortunate to live in a city that has a vibrant technical community and I wanted to contribute something to that community.
If you would like to know some of the benefits of becoming involved more in your local tech community, watch this video (It’s currently free):
The second reason is that when I was in college, I participated in forensics (speech and debate) and miss publicly speaking. I’ve thought about joining Toastmasters or a similar organization, but doing a technical presentation is more accessible and congruent with my career goals.
The final reason is that the best way to learn something is teach it. Teaching a subject requires in depth knowledge and the fear of looking like an idiot encourages you to thoroughly learn your subject material.
I recommend picking something you are personally interested in, and not worry about whether or not you are currently an expert in your topic. Obviously don’t pick something you know nothing about, but don’t be afraid to branch out. Researching the presentation will help you become an expert.
The second step is to research. For my talk, I read Interactive Data Visualization for the Web by Scott Murray and many online tutorials. I also built lots of small demos.
After some research, start building an outline. This outline will probably change with new information, but it’s good to get an idea of what you want to talk about. Having an outline helps focus your research efforts.
While researching, I also built the demonstrations that I used in my presentation. My goal was to show the power of data visualization on the web, so the focus of my presentation was walking through lots of examples.
Tech demos have a tendency to fail, so it’s important to keep things simple and minimize dependencies. I made it a point to make sure my demos didn’t rely on any outside components. No databases, no web services, just local code. I also put my code on Github, so I could easily setup my project on another computer if I needed to.
After building the demo, and the outline, it’s time to put together your talk. If you have slides that you want to use, build those now. I had a few slides, but most of my presentation was examples and code demos.
After that, practice! Try to run through your presentation at least a couple of times. Rehearse in your head and out-loud. Give your talk to the dog or cat. Make sure your timing is good and your transitions are smooth.
Also, don’t write out your talk and memorize it. This will stifle your delivery and ability to go with the flow of your audience. Rehearse your key points and don’t worry about getting everything word for word. Your audience changes with every performance and it’s important to be able to cater to that audience. Memorizing a written speech will prevent that from happening.
So far, I’ve given my presentation twice. Once at the local .NET meetup group and once at my current employer. Both situations were different and provided different learning opportunities.
The one thing that surprised me was the awkwardness of transitioning in and out of PowerPoint presenter mode. My presentation initially consisted of an alternation between slides and demos of visualizations on the web. Unfortunately, PowerPoint made those transitions really awkward. To fix this, I ended up pulling those slides and just showing the demos. Less PowerPoint is not a bad thing.
I ran into another issue when I gave my presentation to my current employer. I didn’t realize that I was also giving my presentation to the non-technical staff as well as the developers. To adapt, I spent more time talking about general data visualization concepts and less time walking through code. I also told my audience that the second part of the talk was more technical. I can’t stress enough about how important it is to cater to your audience.
I was surprised at how well the question and answer portion of the talk went. Studying up for the presentation really paid off.
I also felt like I adapted to changing circumstances well. This is probably because my forensics career in college was spent in limited preparation events, where you need to be able to think on your feet.
I put all of my talk materials on Github, so people could follow along and download the code themselves. I had a number of positive comments about that.
I am glad I made this talk and plan to make more in the future. The whole experience was highly educational and it felt good to make something useful for the community. I can’t recommend it enough.
I used to be a little nervous about doing technical interviews. Even though I spend much of my free time learning about technology, I’m still afraid that I’ll be perceived as an idiot. To combat this feeling, I have developed several practices to improve my interviewing skills.
Every interview I’ve been to asks you for examples from your work history. To prepare for these types of questions, review your resume before each interview. For each job on your resume, think about the challenges you faced, what technologies you used, and what you were proud of. Think about stories you can tell from previous jobs to potential employers. Practice telling those stories in your head or in front of a mirror. This exercise primes your brain. When prompted, you will be ready with a story from your work history.
Depending on the technology stack and what job you are interviewing for, most employers ask a list of standard questions. You will get a feel for this list as you do more technical interviews. I’m an ASP.NET Developer, therefore I get questions on the following topics:
To prepare, you need to research the concept, practice describing the concept, and for more complex questions, come up with relevant examples. For example, when describing OOP concepts, come up with a novel example. Instead of the usual examples of vehicles or animals, try something a little different, like a beer factory or different types of ducks. The key here is to show that you understand the concepts, as opposed to being able to memorize a textbook example.
I learned my public speaking skills by competing in college forensics (speech and debate). It was a great experience that has helped me in many ways. I highly recommend competitive speaking if you have the opportunity. If you are no longer in school, you can join Toastmasters or practice with a group of your peers. Meetups are a good way to find groups of people to practice with. You can also give presentations at user groups and conferences. Practicing your public speaking skills on a regular basis will help you eliminate filler words from your vocabulary and help you learn how to handle fears surrounding public speaking. If you can explain a complex technical concept to a group of thirty people, then you should have no problem with three people in a job interview.
Habits are like cron jobs for the brain. They govern a large portion of our behavior automatically. According to a study by a researcher at Duke University, more than 40 percent of our day to day actions are the result of habits. (1) Fortunately, habits can be reprogrammed.
The habit loop is composed of three parts. Once this loop is established, the habit becomes automatic. These components are:
A cue is what triggers a habit. For example, my cue to eat lunch is that the time is around noon. Cues can take many forms, including specific times (dinner at six PM), mental states (emotional eating when sad), visuals (eating candy on the counter), or preceding actions (brushing your teeth after a meal).
A routine is the action that triggers the reward. This is the behavior you are trying to change.
The reward is what you get for completing the routine. Examples include the sugar rush at the end of a candy binge or the runners high you feel after a hard workout. Rewards are not always obvious. For instance, when I was in college, I would work out with my friends on a regular basis. The reward wasn’t the energy boost from the workout, but the time I spent with my friends.
The key to changing a habit is to identify the habit loop. Once you identify the habit loop, you can change the components of the loop and change the behavior. Here are some strategies that you can use to modify your own habits:
The easiest way to change a habit is to modify your environment. Add cues to trigger good habits or remove the cues that trigger bad habits. For example, I like to put my weights in my living room so I’m reminded to workout. The great thing about environment design is that you can take it as far as you want to go. You could even build a Batcave for Habit Change
Swap the Routine
Charles Duhigg, in the book The Power of Habit, advocates changing routines. This is a good strategy when you don’t have control over your environment. It’s easy to hide the M&Ms in your pantry, but hard to get your office to remove a vending machine. To change a routine, learn to identify the cue that triggers the habit and then try different routines until you find one that delivers the same reward. For example, if you want to kick a morning soda habit, try switching to tea or doing 20 squats instead.
This technique comes from Stoic philosophy. It works by devaluing the reward for a habit. Take something you desire, like a new gadget, and decompose it. For example, the hot new phone is really just a metal and glass enclosure with some copper and plastic inside. Decomposition shows you that the items you desire are not special.
There are certain habits that have the potential to radically alter your life. These are called keystone habits. Keystone habits can start a chain reaction that changes other habits. If you can develop a keystone habit, you can radically alter your life.
Common keystone habits include:
Habits don’t just apply to individuals. Organizations also have habits. Some of these habits are documented in policies and others are a result of organizational culture. Most business books highlight organizational habits. The classic business book Good To Great is about habits that are shared by “great” companies. The Joel Test is a list of desirable habits for software development organizations.
This is an eight part course that’s great for learning the basics of ASP.NET MVC. It’s high level, but I found it useful. The class is done by the Microsoft Virtual Academy, which has free videos on a large number of subjects.
This site has a ton of information about MVC and the exam.
When I was primarily working in Web Forms, my first stop for development information was MSDN. For MVC, I find myself getting most of my information from Stack Overflow.
This is an excellent book that covers almost all practical aspects of building ASP.NET MVC applications. In addition to the basics, it includes information on architecture, optimization, build automation, and deployment. I reference this book often at work. I highly recommend it.
This book has proven to be less useful than the O’Reilly book above. This book covers all of the exam objectives, but some of the chapters are filler and reading this book alone will not give you enough information to pass the exam or build ASP.NET MVC applications. The previous book is a much better source of information. I wouldn’t recommend it for anything other than prepping for the exam.
I recently passed Exam 70-480. Despite the lack of official study material and information regarding what was on the exam, I passed the exam. I am going to share what I did to study for the exam and list some tips so that you may have an easier time studying for this exam.
A list of skills measured can be found here:
I found that the exam closely tracks the list of skills measured. I’ve taken a number of non-Microsoft exams and 70-480 is very straightforward. Most of the questions consist of a block of code and you need to select the proper code block to answer the question. You will need to read the question carefully and know the material, but there are no tricks.
Here’s the list of Microsoft Exam Question Types:
Most of the questions I ran into were multiple choice, repeated answer, and case studies.
I started learning web development in 2001, have been a professional web developer for over six years, and I’ve been tracking the technologies in this exam for several years. These are the things I did to study for the exam: