The next time you give a tech talk or presentation at work, show up early and start a conversation. It’s a great way to get things moving in the right direction.
Ever find yourself in high stakes situations where even the slightest miscommunication can bring everything crashing into the ground? If so, Crucial Conversations has you covered. Crucial Conversations is a book about how to better navigate high stakes conversations. Unlike most business books, Crucial Conversations is packed with actionable information.
Why is this an important skill for developers? People think software development as a process where people in a windowless basement turn pizza and caffeine into software. The reality is that software development is more about communication than technology. We build software in teams. We build software for people. We need to figure out what those people want. We need to be able to have honest conversations when things don’t go as planned (which is always). Creating a free flowing dialog is absolutely essential to creating valuable software.
Beyond building software. Developers who want a lucrative career find themselves in high stakes negotiations. These include, project scope discussions, salary negotiations, and job role discussions. Learning how navigate these situations can add thousands of dollars to your lifetime earnings. Not bad for a $10 book and a few hours of reading time.
Everyone has high stakes conversations. These include high pressure negotiations, impassioned arguments, and delicate interventions. Crucial conversations come in many different flavors. What links them together is that the results of these sorts of conversations have an out-sized impact on your life. Screw up one of these and you could be feeling the pain for years to come.
The key to navigating crucial conversations is to keep a free flowing dialog between the participants. To create free flowing dialog, maintain psychological safety. The primary goal of someone in a crucial conversation is to create and maintain a psychological safe space where both parties can express themselves without fear of anger or retribution. If everyone can get everything onto the table, you can usually figure out the correct path.
To cultivate psychological safety, you need to control your own emotions. Many people cast their own stories into “victim and villain” narratives. Playing the victim causes other people to get defensive. This defensiveness erodes psychological safety. Without psychological safety, people retreat to “silence or violence”. They either shut down or defend themselves with hostility. Usually emotional and verbal hostility, but sometimes physical hostility. Responding to a conversation with silence or aggression is “the fool’s choice”. Avoid the fool’s choice at all costs.
The book describes many techniques to maintain dialog. I’m not going to list them all out here, but a few include:
People generally have some shared goal in the conversation. Reminding people of that goal can inspire mutual cooperation.
Contrast and Clarification
Use contrast to clarify what you want. Prevent misinterpretation. Everyone has a plethora of cognitive biases. It’s easy to misinterpret wants and needs in high pressure situations. Contrast what you actually want with what people think you want.
“Start with Heart”
Figure out what you actually want from a situation and take your ego out of the equation.
Radical candor is where you are willing to challenge people directly, but with a high degree of empathy. It’s the useful alternative to being a wimp or an asshole.
Find out more about it here: https://www.radicalcandor.com/about-radical-candor/
People have a variety of intellectual distortions. These are also referred to as cognitive biases. Watch out for cognitive distortions in yourself or others. There are dozens of these, but Psychology Tools has put together handy chart detailing some of the major ones:
Ego is the Enemy
A big part of being a better negotiation is learning how to disarm your ego. Lots of people forget their mutual goal and try to “win” an argument. This is usually waste of time. Focus more on your goal and less on yourself. Ryan Holiday has a fantastic book about this.
Ego is the Enemy (Amazon)
Being able to successfully navigate tough conversations is an essential developer skill. Crucial Conversations has a variety of techniques to better navigate high stakes conversations. For the sake of yourself and everyone who has to work with you, work on your communication skills.
There are lots of different ways to learn new things. Many of these methods are easy to integrate into your life. We all have a limited amount of time, so I like to use learning methods that capitalize on otherwise wasted time. My primary target is the time I spend in the car. Additionally, there’s so many inexpensive ways to learn new skills. Here’s a few of the ways you can learn some new skills.
The easiest one is to read books. Books are cheap and accessible. If you don’t have a lot of time to read, get yourself an Audible subscription. Most books are also available in audio form.
College courses are nice, but there are better options. The Great Courses publishes classes taught by leading professors. I like to listen to them on my way to work. You can also access college level courses through moocs like EdX, Coursera, and iTunes U. Additionally, Udemy has a wide variety of inexpensive courses (wait for their $10 sales).
In order for your hard-won knowledge to be useful, you need to remember it. One method I use to learn better is to keep a commonplace book. A commonplace book is a collection of notes and quotations from the things you’ve read. This used be a common practice, but it’s coming back as people discover how useful it is. I record notes on anything interesting that I read. I also collect scraps of articles and interesting quotations. I keep these in a OneNote notebook that I can refer to. I also review things I’ve read before and add to my commonplace file. This cycle of note taking and review helps me get more out of what I read.
Organizations / Clubs
There’s a meetup for everything. Go find a group of people you can learn from. It’s often easier to talk to someone than to scour the Internet for resources. I’m looking into more agile groups to expand my business skills.
This is one of the best ways to pick up new skills. If it’s a “maker” skill, like design or programming, build something. Side projects are a great way to learn something new. If it’s not a “maker” skill, like psychology, make something with the knowledge. Write a blog post or a talk. I never feel like I’m proficient until I use my knowledge to make something.
If you want to be more successful, learn a new skill. Each new skill makes you a more useful person. If you want to be more creative, diversify yourself. Diverse knowledge gives you more resources to draw from. If you want to win at work, be a jack of all trades, master of one. There are lots of learning resources at your disposal. Put them to work for you.
Usefulness should be your primary criteria.
Let’s unpack that a bit.
Software is a tool. We use it to build things of value for people. Either our customers, our users, or ourselves. We build to provide valuable software for people. A lot of developers lose sight of this when they look into new technologies. They fall in love with a technology because it’s shiny, or interesting, or scratches an intellectual itch. It’s the old “golden hammer” antipattern. Find something shiny and use it to build everything, even if it’s not the best tool for the job or doesn’t really improve upon existing technologies. We can do better. By focusing on what’s useful, we can skip the majority of new technologies and keep our sanity.
To figure out what’s useful, we need to ask a few questions. Write down your own answers as you read through this exercise.
As developers, we serve one or more audiences. Each of these audiences has different needs. It’s your job to figure out which audiences you serve (or want to serve) and what they need. Perhaps you are spending most of your time in a full-time job, but want to start your own business. Perhaps you just work for the man. Figure out which audiences you serve and their relative priority. If you want to serve a new audience, think about what you will need to learn for them as well. Additionally, look for synergies. If you have more than one audience, find overlapping technologies.For example, if you want to build your own business on the side, use a similar tech stack to the one you use at your job.
Here’s a few audiences you can serve:
Public Code / OSS
Open source projects have different goals than enterprise shops. There’s some overlap, but OSS is built differently. If you do OSS, figure out which projects you want to contribute to and focus on their tech stacks. Also think about what value you can bring to the developer community.
If you run an app business or an ISV (independent software vendor), focus on technologies that create customer value. For example, while functional programming is cool, you’re better off mastering digital marketing or product design instead. Focus on technologies that help you get products in front of customers quickly. This doesn’t always mean new technology. There are a lot of Rails 2, jQuery, and ASP.NET Webforms apps out there still generating significant value for their customers.
It’s OK to learn something just for fun. Lots of people write code as a hobby, but make sure you understand that the time you spend building robots or smartwatch apps is hobby time, not professional development time.
I have three audiences. I work on a team that builds data driven applications using .NET Core, Angular, TypeScript, and Spark. I also serve the broader technical community by speaking at conferences and blogging. Eventually, I want to build a small software product and sell it. I achieve synergy by focusing my community efforts on things that I either use in my day-to-day work (like Angular) or things that will serve me in business (innovation).
Now that you know what’s useful for your situation, let’s use that knowledge to make your life easier. You likely have a list of technologies that you’re interested in or feel obligated to keep up with. I have a whole radar of them. Take that list and run it through the criteria you figured out. If the technology doesn’t help you add value to one of your audiences, cross it off the list. Rank everything else based on its relative value. Use your criteria to combat “shiny object” syndrome when you encounter a new technology. You’ll likely still have more things on your list than you can learn, but your list should be manageable.
As technologists, we are the vanguard of innovation. We’re at the forefront of technological innovation. Even if you’re slagging COBOL in the basement of some bank, you’re still dragging your organization into the future. Ever wonder how that process actually happens? What can you do to be more creative?
I’m fascinated by this topic, so I put together a talk about it. (abstract / slides) It distills what I’ve learned from reading dozens of books on innovation and the history of technology. To save you some time, I put together a list of my favorite innovation related reads. If you’re curious about this topic, these books are a good place to start.
Sapiens is a highly entertaining, unorthodox view of human history. Not only is it informative, it challenges basic assumptions about ideas that most people don’t realize they’re making. It’s a great description of early human history and how we got to the modern age. It’ll really open up your mind.
Innovation is not evenly distributed. There are certain times and places throughout history that have “golden ages” of innovation. Geography of Genius explores a few of these places and tries to find what ties them all together. This book is very interesting and you’ll learn about some places that you don’t see much of in the classroom.
Unlike what the history books tell us, innovation is more bottom up than top down. Matt Ridley does a fantastic job describing how in Evolution of Everything. He covers a several major innovations including religion, money, and government. This book challenges many deeply held beliefs and illustrates how innovation is an evolutionary process.
This book offers a more tactical look at creativity. It’s also a great guide to improving other aspects of mental performance. Charles Duhigg does a fantastic job mixing science with fascinating stories.
Creativity requires concentration. A commodity in short supply in the modern age. In Deep Work, Cal Newport makes a compelling argument for making “deep work” (focused work) one of your primary priorities. I changed several of my habits after reading this one.
While I enjoyed the Lean Startup, I felt like it treated innovation more like a roulette wheel than a process you can influence. “Just pivot until you make it big or run out of money.” In Competing Against Luck, Clayton Christensen describes a fantastic intellectual power tool for building new products. The “Jobs to Be Done” theory of innovation. If you want to build a product, I highly recommend this one.
One of the most important things you can do to become more innovative is empathize with and learn from people whom you disagree with. We live in a society that’s increasingly polarized, but this book the antidote. In the Righteous Mind, Jonathan Haidt explains the moral foundations for different political outlooks and makes a strong case for civility in political discourse. This is a must read if you have trouble dealing with people who don’t share your beliefs.
Here are a few non-book resources to check out:
Kevin Kelly’s concept of protopia (as opposed to utopia or dystopia) is really enlightening.
In How to Fail at Almost Everything and Still Win Big, cartoonist and business author Scott Adams describes his “success formula”. Each area you master roughly doubles your odds of great success. This is a great case for diversifying yourself. You can either get his book or read this article:
If you’re looking to diversify yourself, here are two excellent resources:
The Personal MBA is a reading list that’s meant to give you the business skills taught by an MBA program. I’ve read many books on this list and have not been disappointed. It’s also got great selections on personal finance and psychology.
The Great Courses are a series of college level lectures that you can listen to in your car. Personally, I’m a big fan of their history selection. They also have courses on psychology, philosophy, and business.
Innovation is partly a network effect. This article describes why cities with a higher population density have higher per capita rates of innovation.
Everything is a Remix is a video series about cultural innovation by Kirby Ferguson. I have yet to find a better description of how culture is generated by remixing other cultural elements.
This is a TED talk on how Google X (Google’s own skunkworks company) takes risks and creates a culture that fosters psychological safety.
This list of resources will open your mind and help you become a better innovator. If you think I missed something, feel free to drop it in the comments.
Have you ever built something you’re proud of, only to have it torn to shreds when you show it your audience? Get burned in a code review? Rejected after a job interview? I know I have. Today, I’m going to write about some strategies to deal with it.
If someone is able to show me that what I think or do is not right, I will happily change, for I seek the truth, by which no one was ever truly harmed. It is the person who continues in his self-deception and ignorance who is harmed.
― Marcus Aurelius, Meditations
One of the most underestimated soft skills of the modern software developer is the ability to take criticism well. This is an industry where things change so quickly that there’s no way to be perfect. There is always someone who knows more than you and even if they don’t know more than you, you can certainly learn from them.
Besides being bad at taking criticism, most developers are not good at giving good criticism. Anyone can slag another person’s creative output, but how often can someone say something that helps the person they’re critiquing? Being able to deliver a useful critique is almost as valuable as taking one. Software development is a complex craft and being able to help others is essential.
One particularly powerful sting-elimination strategy is to consider the source of an insult. If I respect the source, if I value his opinions, then his critical remarks shouldn’t upset me.
– William Irving, A Guide to the Good Life: The Ancient Art of Stoic Joy
I’m going to define criticism broadly. To me, criticism includes any comments you receive on your creative work. It includes well meaning advice, sharp attacks, and trolling. It also includes situations when you don’t get picked for the job, get passed over to speak at a conference, or lose a contest. Call it criticism from life. Regardless of the source and intent of the criticism, the following tips apply.
Don’t take it personally.
Even if someone meant to harm you, you choose how you respond to criticism. You can choose not to interpret it as insult. At the end of the day, all criticism is information. Treat it like any other data stream. Some data is higher in quality, some data is lower in quality, but it’s all just data.
The reality is the people who sling insults are not doing it because of you, they’re doing it because of their own issues. You can’t control them, but you can control you.
Mine for actionable feedback.
When someone criticizes your work, even if they were trying to hurt you, look for things you can improve on. For example, let’s say your users throw some scathing criticism your way in a product review. While it’s easy to get angry or frustrated, try to figure out the root cause of their pain and use it to improve the product. If you get rejected for a job, try to think of where you went wrong and fix those things in future interviews. Remember, failure is temporary. Learning is everything.
Sometimes, you are going to get comments that have no useful information. Trolls excel at leaving useless criticism. If you can’t find actionable advice, then disregard the comment. Remember, people being mean is their fault, not yours.
Consider the source.
Like in the quotation above, it’s important to consider who is criticizing you. Do you respect them? Are they considered experts this particular area? Do they adhere to the same philosophy as you? Use these considerations to weigh comments. Do you think that Peter Thiel, Elon Musk, Ray Kurzweil and others like them care one shred about what luddites think about them? I doubt it.
Giving good criticism is almost as important as being able to take criticism. Being able to deliver useful feedback to your peers helps them grow. Being able to do it in a way that doesn’t make them hate you is good too. Here are a few tips to help you with that.
Be mindful of other people’s egos.
While it’s easy to say that you should make all criticism into dispassionate feedback, actually doing it is hard. I still have a ways to go myself. Because of this, you should make it as easy as possible for the person you are critiquing to turn what you say into useful feedback. An important way to do this is by being mindful of their ego.
Software development is a tough craft. People invest their time and energy to get good at it and a well timed insult and can trigger all kinds of pain. If you want to see how fragile people’s egos are, Google “imposter syndrome”.
To help preserve ego, start with compliments. For example, I attended a session last year that had some content issues. When asked how it went, I started off with the good things about the session. I complemented the presenter on their topic selection and presentation style, which were both excellent. Then I made a point about how they tried to do too much for their time slot. This gave the person something they could use without hurting their feelings.
Remember that negative feedback has more weight than positive feedback. Start off on a positive note and try to achieve at least a 2:1 ratio of positive to negative comments. (if possible)
Focus on giving actionable advice.
Telling someone “that sucks” does nothing useful for either party. You don’t get a better product/employee/code and the person being criticized doesn’t learn anything. Additionally, you’ve angered the person you are critiquing, which benefits no one. Instead, focus on making things better. Try saying “This would be better if…” or “These X things would improve your product because of Y reasons”. Using direct, but non personal phrases focuses the attention to where it needs to be. Remember, there are no bad people, just bad ideas.
The key lesson for this post is to always look for value in criticism. When someone criticizes you, focus on extracting useful information from the experience. Use it to fuel your abilities to the next level. When critiquing others, try to focus on making it easy for them to find value in your comments. Help them get to the next level. Remember, criticism is just data. You choose how to use it.
Roman Emperor and Stoic, Marcus Aurelius
Photograph by Jean-Pol GRANDMONT
Staying well informed is important to every professional, but how do you navigate the sea of infinite content? How can you filter out useful information from political nonsense, irrelevant junk, and clickbait? As someone who tries to focus the essentials, I don’t want to waste time separating the good from the bad. I want useful information that helps me in my life. To address this need, I’ve created an information funnel. I get news from a variety of sources and filter out the best stuff. In this post, I’m going to describe my information funnel and how you can use a similar process to get your own slice of news.
The most important thing to do when trying to find good information is defining what you are looking for and what you want to avoid. I’m looking for the following things:
This list represents a combination of things I need for my job, things I’m interested in, and potential future technical investments. I’m interested in a lot of different things, but the goal of this list is to focus on the technology.
I also want to avoid any unactionable news. If it doesn’t help me, then I generally don’t care about it. Heres some examples:
Additionally, I don’t want to waste a lot of time finding news. Being well informed is a good, but this endeavor has diminishing returns. News is the information equivalent of carbs. You need a few, but not too many, and you want to stick with high quality sources.
The next step is to find decent news sources. This is a huge challenge because there are so many news sources. I get my news from a variety of places and have tried various methods of filtration to avoid the junk. I find that a combination of Podcasts, RSS, Twitter, and Prismatic works well for me. I get a variety of sources, which is important to avoid filter bubbles, but I also get some selection, so I’m not buried in junk.
Here’s a list of news sources I use now or have tried in the past:
I listen to a variety of podcasts on technology. Podcasts are great for getting in depth information about technical topics. Podcasts are also great because you can listen to them while doing other things, like driving to work. It’s a good way to multitask. The only disadvantage is that podcasts can be long. Here’s two of my favorite podcasts:
While other media has chipped away at my RSS feeds, I still subscribe to a few blogs. RSS is good for following specific products or people. The disadvantage is that you can get behind if you subscribe to too many news sources. I subscribe to less than 20 feeds.
I get a lot of news on Twitter now. There are two things I like about news on Twitter. First, because it’s a social network, the good stuff tends to find it’s way to the top. Second, if I don’t pay attention to it for a while, I don’t have a huge inbox waiting for me when I come back. It’s also great for keeping up with organizations, like PEW or the Visual Studio team. The big disadvantage of Twitter is it can be a cesspool of ignorant political bickering. You can’t have a political discussion in 140 characters. The key is following the right people. I tend to unfollow folks who use Twitter for politics or idle chit chat.
I’ve recently started using Prismatic. It’s a service that delivers content to you based on your interests. It also tries to learn from you and deliver increasing good content (like Pandora for news). I’m still getting the hang of it, but Prismatic offers interesting articles. I check it every few days. The key to making Prismatic work is only starting with a few interests. I’m interested in a lot of things, so I checked lots of boxes and had to filter out a lot of noise. I ended up removing about 2/3’s of the interests I started with.
I used to read Hacker News, but it’s become too whiny and political for my tastes. Hacker news still has some good stuff though. I check it once in a while.
Google News is good for getting news for a lot of sources, but it’s not specific enough for me. Google Now, however, has delivered some interesting content to my phone. It’s finds things related to what you’ve searched for or read in the past. My biggest Google Now win is when it delivered the answer to a problem I unsuccessfully searched for the previous day. It’s creepy, but amazing.
I’ve recently started using Reddit. While I don’t use it for tech news, you could. There’s a subreddit (a topic specific group) for almost every technology. I found that the same thing that applies to Prismatic also applies to Reddit. It became much more useful once I stopped following so many topics.
I prefer to do my reading in long sessions, so I use a “read it later” app to save links. I check the sources mentioned above when I get bored and save anything interesting to my “read it later” app of choice (Pocket). I ignore the vast majority of what I see, but filtering has gotten easier as I’ve gotten better at selecting news sources.
If I find something good, I’ll save it to Evernote so I can refer to it later. I only do this for evergreen articles that won’t lose their value over time. Usually these are on business development, software best practices, or personal development.
Separating the signal from the noise is tough in the age of infinite content, but we have many tools at our disposal. What do you do to stay well informed?
Being called the smartest person in the world makes you huge target for trolls. Marilyn vos Savant was listed in the Guinness Book of World Records under “Highest IQ”. This propelled her into the national spotlight. She then proved that IQ doesn’t mean everything by becoming columnist for Parade. The listing also made her a popular target of criticism, especially by academics. There are whole websites devoted to proving her wrong. This is not one of them. This is a story about how she was right and what we, as software developers, can learn from her experience.
The Monty Hall problem is a famous math problem that’s based on an old game show called “Let’s Make a Deal”. The game begins with three doors. One of the doors has a fabulous prize. You don’t know what’s behind any of the doors and each door has an equal chance of containing the prize. You are then asked to select a door. After selecting your door, the host of the show reveals one of the other losing doors. You are then given the option to switch.
The question is:
Would switching doors give you a better chance of winning the prize?
The intuitive answer is that switching doors provides no benefit. Remove one door and your 1 in 3 chance becomes a 1 in 2 chance of winning. Since each door has an equal chance of being correct, the remaining door isn’t any better than the one you picked. This is the answer most people come up with when they first hear this problem.
This logic, while intuitive, is flat wrong.
The correct answer is that switching gives you a 2/3 chance of winning, as opposed to your 1/3 chance you have sticking with your door. The key to this problem is that revealing one of the incorrect doors doesn’t change the initial probability. You already know one of the doors is going to be wrong. What is important is that the host is basically giving you the option to select two doors instead of one.
Here’s another way to think about it. Switching and losing means that your initial selection was the right one. Your probability of winning with your initial selection is 1/3. Thus, the probability of you losing when you switch is 1/3, which means your probability of winning is 2/3.
If you still don’t believe me, the Khan Academy explains this problem well:
Marylin vos Savant answered this same question in her column in 1990. Even though she was correct, the public sent her a truckload of hate mail. Many academics also piled on the criticism.
Here’s a sample of the feedback she received (Source):
Since you seem to enjoy coming straight to the point, I’ll do the same. You blew it! Let me explain. If one door is shown to be a loser, that information changes the probability of either remaining choice, neither of which has any reason to be more likely, to 1/2. As a professional mathematician, I’m very concerned with the general public’s lack of mathematical skills. Please help by confessing your error and in the future being more careful.
Robert Sachs, Ph.D.
George Mason University
May I suggest that you obtain and refer to a standard textbook on probability before you try to answer a question of this type again?
Charles Reid, Ph.D.
University of Florida
And my personal favorite:
You made a mistake, but look at the positive side. If all those Ph.D.’s were wrong, the country would be in some very serious trouble.
Everett Harman, Ph.D.
U.S. Army Research Institute
It took Marylin several tries to explain the concept well enough for the majority of her readers to understand it. I found her explanation to be clunky, so I posed the problem to my Facebook friends. What resulted was the longest comment string I’ve had in a long time. My friends, several of whom have advanced degrees, had a tough time with the problem. The people who knew the correct answer had a tough time explaining it to the doubters.
There are several lessons this story can teach us about psychology, thinking things through, and humility.
This story illustrates that people are not good at understanding probability. There’s a whole slew of cognitive biases (brain fails) related to estimating probability.
This is important to software development because much of what we do is estimate and mitigate risk. For example, mitigating security risks is incredibly important. Due to our inability to measure risk well, we may spend resources fixing low risk problems that were recently featured in the news instead of fixing high risk issues.
Risk also factors into software estimation. People are terrible at estimating how long it takes to do anything over a day. This is why agile software projects measure tasks using relative complexity (story points, T-shirt sizes, etc…) instead of hours. Agile projects also break down work into bite sized pieces, which are easier to comprehend.
Another important aspect of software development is filtering out irrelevant information. In the Monty Hall problem, the host opening the losing door doesn’t change the probability. You already knew one of the doors was a losing door. I find that it’s important to remember this when I’m debugging code. Good testers tend to report more information than you need and it’s up to you to figure out what’s useful and what’s not.
Many of Marylin’s critics were highly educated. All three of the quotations I mentioned were from PhD’s, including one professional mathematician. In our society, we tend to take the opinion of experts at face value. Pew Research recently did a survey on the beliefs of scientists vs the beliefs of the public. (link) This survey was widely reported on.
While the opinion of experts is vital, remember that they specialize in narrow areas. Any opinions they have outside of those areas should be subject to the same scrutiny that you give any smart person. Too often, people who are experts in one area are considered experts in other areas as well. A good example of this is when the media asks famous actors about their opinions on political issues. The tendency to allow irrelevant traits, such as beauty or skill in an unrelated field, to effect our judgement someone’s ability is called the halo effect.
You can use the halo effect to your advantage. Dressing sharp and being a good conversationalist can increase your credibility. While it’s acceptable to go a tech conference in a t-shirt and jeans, people will think you are more professional if you wear something nice.
The halo effect also applies to software. In the book Emotional Design, Don Norman explains how people find aesthetically pleasing objects to be more effective. When building your own software applications, pay attention to the design of the interface. Making things look good will make your software appear to be more useful.
When doling out criticism, be nice. It hurts a lot less if you’re later proven wrong. This doesn’t mean you should sugar coat things, but you can deliver sharp criticism without being mean about it. Many of the people who wrote in nasty comments ended up apologizing for it once they realized their mistake.
The story of Marilin vos Savant and the Monty Hall problem has many lessons for software developers. If you want to learn more about the topics in this post, check out the resources below.
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.