There’s nothing like replacing a legacy software system to stoke the fires of self-righteousness. You get to pull some poor users out of the dark ages and save them from a system may have been state of the art last decade, but is junk now. (Ignoring the fact that the old system lasted that long because it did what it what the users wanted it to do.) It’s especially fun when the old system is so laughably bad that it was obsolete the day it was written. Unfortunately, these projects come with a few pitfalls.
The first pitfall is that you can end up building the same legacy system in a new technology. It’s hard to transfer old paradigms into new ones and if you’re not careful, you can end up repeating old mistakes. I worked at a company that was creating an ASP.NET web app built over an existing database. Many of the tables in this database had no keys or relational data. The original system was built on a mainframe using flat files. When that system was upgraded in the 90’s, the flat files were just copied over. There was no regard to modern relational database structuring. When the ASP.NET version came along, the plan was to just copy over each of the old pages, one by one. Management didn’t take modern web and object oriented practices into consideration. Needless to say there was some debate between the developers and management.
The second pitfall can come while gathering requirements. When gathering requirements for the new system, it’s easy (and often correct) to reference the old system. There are two problems using the old system as the primary reference for requirements. First, the system sometimes does things a certain way because of technical constraints. I once worked on replacing a system that had lots of batch processes. Many of those processes were not needed because modern systems were fast enough to process those records on the fly. Second, many times, old systems don’t reflect the business practices of people who use them. There are lots of instances where users have to do something convoluted to get their old system to behave how they need it to. Watch out for these types of scenarios, fixing them is a good way to score brownie points with your customers.
The third pitfall happens when the builders of the new system don’t recognize the advantages of the old system. In the system I mentioned in the first point, the legacy system allowed for rapid keyboard entry. The new system, being a web application, did not optimize for keyboard entry. In the beginning, the developers ignored the users because of the “obvious” superiority of the new way of doing things. Eventually, we realized our error and created a keyboard entry optimized set of web controls. The users were much happier. While it may be fun to mock the old system, you should also pay attention to your users and make sure you aren’t creating a system that’s worse than what they started with. Just because it’s pretty and new doesn’t mean it’s good for the customer.
1. Make sure your new system is using new paradigms. Don’t repeat legacy design.
2. Be careful when gathering requirements from the old system. Especially when it comes to implementation details.
3. Don’t make a new system that’s worse than the system you’re replacing.
Last year, I created my first tech talk and delivered it to several venues. I enjoyed the experience, so I decided to produce a new talk this year. This time though, I want to document the process of building the talk while I’m working on it. I think it’s important to see things unfold while they happen. Often, you see a polished talk and you don’t see the work that has gone into it. This isn’t meant to be a list of recommendations from on high, but a log of how I like to build talks. Feel free to use what works and forget what doesn’t.
Last year, I gave two versions of my D3.js talk in five different venues. I’ve also delivered several talks at work. Additionally, I did speech and debate in college for two years. While I’m no Scott Hanselman, I know my way around a lectern.
Last year, I picked a topic I didn’t know much about (D3.js). I picked that topic because I knew building a talk would force me to learn about it. This year, I want to deepen my understanding of a topic I have experience with. I work with ASP.NET MVC in my current job. Additionally, I enjoy building UI components. When I started using ASP.NET MVC a few years ago, I had a hard time finding information. The books on MVC cover the basics well, but the reference material is incomplete. (Example) Doing a talk on building UI in ASP.NET MVC would deepen my own knowledge while helping others.
Building UI in ASP.NET MVC is a broad topic, so I drafted a list of subtopics to help me narrow my scope down.
Here’s my, clustered into similar topics:
Editor and Display Templates
Grunt / JS automation
LESS and SASS
Bundling and Minification
UI Testing (like Selenium)
That’s way too many things for an hour long talk. Each of the above clusters could be it’s own talk. To narrow the scope, I’m going to remove anything that doesn’t have to do with building UI components. This leaves me with the following list:
Editor and Display Templates
Now that I have a topic list, I want to create a theme for the talk. A theme gives structure to the talk and provides a narrative for people to latch on to. I believe that in software development, you should bake good defaults into easy to use components. This lowers the cost of development and increases the quality. Good components allow you to create a great user experience without having to drop a ton of code on each page. My theme for this talk is going to be how to build better software in less time.
Another thing I’m trying to do with this talk is build in more stories. Stories are one of the primary ways people communicate. Studies show that stories engage emotions, which provides a stronger connection than raw data.
The next step is generating an abstract. An abstract is a summary of you talk that you can submit to conferences and user groups. It’s important to have a strong abstract because that’s how your talk is picked by conference organizers.
Here’s my abstract:
ASP.NET MVC UI Recipes: Build Better Interfaces With Less Code
Who doesn’t want to get more done in less time?
ASP.NET MVC gives us an excellent toolset for building web applications. Unfortunately, due to it’s rapid evolution, good documentation is hard to find. However, using some simple techniques, you can build user interface components that can speed up development while maintaining a clear separation of concerns. In this presentation, we’ll learn how to build custom controls, templates, and custom validation. Save time while creating cleaner code.
The next step is building an outline. I don’t memorize my speeches, so the outline is what I study when I prepare. I use my outline to put my topics and demos into a logical structure. I tend to capture a lot of detail in my outlines and then make a simpler outline for reference. I haven’t finished my outline yet, so I’m not going to share it.
This is the first in a series of blog posts documenting my process for building tech talks. As I mentioned before, feel free to use what works and forget what doesn’t.
The more I learn about software development, the more I notice the things I don’t know. Each tactic I pick up or lesson I learn just leads to more questions. It’s like lighting a candle in the dark and realizing that you’re in a room full of doors. Then, as you open each door and turn on the light, you find more rooms to explore. When I started out, I was so sure of myself. Each problem had the “one right way” solution. Now, when I see a problem, I see several imperfect solutions, each with their own trade offs.
This seems like a common problem.
John Sonmez feels the same way:
Simple Programmer: The More I Know, the Less I Know
So does Scott Hanselman:
I’m a Phony. Are You?
They aren’t the only ones either.
Psychologists call this the Dunning–Kruger Effect.
The Dunning-Kruger Effect is when unskilled people overestimate their abilities and skilled people underestimate their abilities. As you become better at something, you realize how little you know. It’s like getting to the top of the mountain only to find that you are at the bottom of a way bigger mountain. It sucks.
This concept has huge implications in software development. Software development is a complex field filled with people who have strong opinions. This creates situations where confident, unskilled people have an advantage when determining technical direction. This can lead to poor choices and technical debt. It’s easy to trust someone who’s confident over someone who isn’t sure of the right answer. Even when not being sure of there is a right answer is the right answer. (This explains most of politics, but I digress…)
What can we do to counter this effect during technical discussions?
If you’re unsure of yourself, don’t be afraid to present the facts and make your case anyway. It’s better to be wrong than to allow bad ideas into your project. You probably know more than you think.
If you’re confident of a particular solution, look for alternative view points. Let the other side make their case. Realize that the person who has a few years of experience on you may know something you don’t. Even if they have trouble articulating that knowledge, it’s your responsibility to listen. You may learn something.
If you’re a manager trying to decide between two viewpoints, don’t let the louder person automatically win. It’s easy to side with people who are confident or articulate, but it’s important to hear out both sides.
What about when you’re just feeling unskilled?
For me, the best way to feel competent is to write code. The code doesn’t care how smart you feel that day. If it works, you win. For me, adding value makes me feel competent. If I can pull off some complex functionality or learn something new, I feel like I know what I’m doing.
Have you ever wished that you had a manual for how to live the good life? A guidebook that will tell you how to make the best decisions. I certainly do. John Sonmez has taken a crack at this task with his latest book, Soft Skills: The Software Developers Life Manual.
The core premise of Soft Skills is that being a good software developer starts with being a good person. By “good”, I mean someone who has their life under control, makes good life decisions, and can achieve their goals.
Soft Skills is a book about a lot of things. It covers general career skills, like interviewing, setting career direction, and marketing yourself. It also covers skills that increase your job performance, like learning and productivity. Additionally, it covers general life skills, like managing your finances and fitness (mental and physical). Soft Skills reads like a summary of many of the top business and self help books.
While the book covers many topics, it does so in bite sized pieces. Chapters run around 5-10 pages each, so it’s easy to read and reference. Since most of the topics stand alone, it’s also easy to skip around and focus on the topics that interest you the most.
These are a few concepts from the book that I found useful.
Instead of having an employee mentality, software developers should treat themselves as a business. Their primary asset is their ability to produce working software. Adopting this mindset makes it easier to think clearly about career choices and gives you a sense of autonomy. Like any other business, you must invest in improving your assets (aka. human capital), and market your skills.
Software developers have three routes for advancement, each with advantages and disadvantages. This book dissuaded me from considering freelancing as a future career goal. The routes are:
Marketing is multiplier that can catapult your career into the stratosphere. You marketing yourself by helping out your fellow developers. You can do this in a vareity of ways, including writing, speaking at conferences, and making videos.
The finance information in this book is great. John “retired” at age 33, so you know he’s doing something right. I enjoyed reading about the ups and downs on his journey to financial independence. He covers a variety of topics, from general finance to the different types of investments.
One of my favorite things about John Sonmez, whether it’s his books or his videos, is his attitude. John is upbeat and pragmatic. He doesn’t believe in zealotry, which is something that plagues our industry.
This is a good reference book for any software developer. People who are early in their careers will derive the most benefit, but it’s a good book even you’re a few years into your career. I wish I had this book about eight years ago when I was graduating college. If you are well read in the topics the book covers, you may find the content a little shallow, but I’m happy with my purchase.
I love to read. I’ve read over 40 non-fiction books in the past year (and all five Game of Thrones books). One of the problems I ran into is that when you read a lot, it becomes hard to recall what’s in specific books. Reading is a waste of time if you can’t recall what you’ve read.
To solve the retention problem, I use a four step process to remember more of what I’ve read. I base this process on what I’ve learned from a speed reading class I took in college and reading about the psychology of learning. I find that following this process allows me to read more books and remember what’s in them.
This method works best on non-fiction books. Recent examples that I’ve read include Drive, So Good They Can’t Ignore You, and The Art of Learning. Most non-fiction books range from 200-500 pages and usually focus around a single primary thesis. Generally, there’s about 50-100 pages of valuable content mixed in with a few hundred pages of
filler supporting material.
This process is based on two core principles from psychology.
Repetition increases retention. Everyone who’s been through school knows this. Often, you get more out of reading something fast several times than one slow reading. Additionally, processing an idea in different ways will help you retain more knowledge. To increase retention, process knowledge in at least two different ways. It’s also important to actively process information. It forces you to recall the information and exposes gaps in your knowledge. For example, read something and talk about it with your friends or listen to a podcast and write a one page summary.
When we learn things, we organize the knowledge in our heads into an organizational pattern called a schema. I like to think of schema as a tree of knowledge. The basic facts are the trunk, the major functional areas are the branches, and details are the leaves. When learning a new topic, it’s important to get a high level view to create a structure on which you can attach details to. Here’s an example from: Psychology – Wikipedia. Notice how the whole field of psychology is structured into branches of increasingly grandular detail.
This process focuses on building up a schema while exposing yourself to the ideas of the book several times. While it seems counter intuitive, this process doesn’t take any more time than reading books from cover to cover.
Begin by looking at the title, author, summaries, and reviews. I start with Amazon for reviews and Wikipedia for summaries. Google/Bing is your friend. The reason we do this is to get an idea of what the thesis of the book is and to find any useful criticisms of that thesis. This gives you a foundation to hang other facts off of and additionally gives you an idea of the other side of the argument.
For example, I recently began reading the book Grain Brain. Before I began reading, I wanted to get some background information on the book.
I started off with the Amazon page.
Decent summary and reviews:
Grain Brain (Amazon)
Most of the reviews of the book are positive, so lets find some different viewpoints. I did some Googling and found some decent resources:
A news article on the book:
A low quality criticism of the book (lots of straw men and cherry picking):
A much better critisism of the book:
Based on those resources, the book has useful information. There are some issues surrounding the extremeness of the authors recommendations. Now that I understand the basic premise of the book, I can focus on the details.
Another way to get a book summary is to listen to a podcast about the book. Many authors like to go on podcasts to market their books and talk about their ideas. I’ve learned about several books by listening to podcasts about them.
Next, open up the book and look at the table of contents. This will give you an idea of how the book is structured and may point you to useful resources. For example, I recently finished reading Drive. When I opened the table of contents, I noticed that the author includes a short summary in the back of the book. I read that part first to get a feel for the book. After examining the table of contents, read the introduction and conclusion of the book. At this point, you should have a good idea of what the book is about and what information the author is going to use to support their thesis.
By the time you get to this point, you should already have a good idea of what the author is going to say and how the book is structured. The advantage of pre-reading is that you can now focus on the details.
This gives you two options. First, you can read the book quickly, grabbing details that jump out at you. Most non-fiction books contain a lot of filler. It’s nice to know you can skip over it without missing anything important. I use this tactic for general business books, like Good to Great. Most of the time, there’s about 50 pages of useful information sandwiched between 300 pages of fluff. Second, you can carefully read the book. Because you’ve already learned the basics, it’s a lot easier to pick up the details. Which path you take is dependent on your interests and the quality of the book.
To further increase retention, you need to process the book in different ways. Preferably active ways that require you to recall the information you’ve learned. I like to talk about interesting books that I’ve read with the people around me.
Another way to increase retention is to keep a commonplace book. A commonplace is a set of notes and quotations from books that you’ve read. Many famous historical figures kept these, sometimes copying large swaths of texts into notebooks for future reference. For each book I read, I create a one page summary and file it in OneNote. Forcing yourself to recall and process your book helps to lock in the knowledge.
Follow these four steps to increase your retention and get more value out of the non-fiction books you read. This tactic is a great way to learn new skills and improve your life.
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.