Tell us a little bit about yourself
My name is John M. Wright and I’ve been a professional software developer for about 18 years. I currently work for Stack Overflow, and for a little more than a year, I’ve been speaking at technical conferences and user groups throughout the middle section of the United States.
I enjoy sharing my experiences with automated testing, mocking frameworks, and static analysis tools, or guiding other developers through the darker crevices of the .NET framework, and learning from my peers’ experiences — helping everyone “level up” as a team.
For over a decade, I’ve lived in the western suburbs of Chicago, Illinois, where I enjoy spending time with my wife and teenage son. Before that, I grew up in Castroville, Texas, a small town in the middle of corn fields and cattle ranches to the west of San Antonio, Texas, then lived in Austin, Texas for another decade before moving north to escape the Texas heat.
How did you get started in programming?
When I was young, my parents bought a Tandy 1000. This was back in the day when you ran MS-DOS on one 5.25″ floppy drive and your program onthe other 5.25″ floppy. It came with an 8088 processor that ran at something like 5MHz. I would tinker around with the PC, reading the source code for the batch files and QBasic programs. My mom likes to tell a story about me finding a bug in one of the batch files used in the game King’s Quest II and calling the support line for Sierra Online to not only tell them about the bug, but also how to fix it. This would have been in the late 1980s, which would make me around 10 or 11 years old at the time. Apparently, they were so impressed, they sent me a free copy of another game.
By high school, I was building computers from parts (something my dad helped me learn) and knew I wanted to work with computers for a living. In ’97, I used some scholarship money to build the PC I would take to college, but didn’t have enough money to buy a hard drive, so I “borrowed” a 100MB HDD from my dad that had 20% bad sectors on it. It was enough to load Windows 95 and the Borland C++ compiler I purchased from the university bookstore, and I was hooked for life.
While earning my Computer Science degree, I worked in the university computing center, where I helped maintain the DEC VAX mainframe clusters that ran the university, and watched the full-time employees panic over the pending Y2K doomsday. One of my coworkers there helped get me a job at a startup in Austin, TX, where I wrote Linux programs, mainly in C, along with some Perl, Bash, PHP and TCL, while I finished my degree. Around that same time, Microsoft came out with .NET, and I started picking that up on the side. The idea of not having to manage my own memory and using WYSIWYG UI editors was exciting, and I moved full-time into the .NET ecosystem a few years later.
And now, after having written all that down, I’m reminded how amazingly far our industry has come in just the last 30 years. I have another 20 or so years before I retire — I can only imagine what it will look like by then!
What type of applications do you develop?
The team I’m on at Stack Overflow is focused primarily on back office and administrative support systems. This means a lot of billing/invoicing related code, reporting, and system integrations. A couple of example of systems my team maintains:
- A “Sales Dashboard” that provides insight into the sales teams’ progress and commissions, with integration to Salesforce to distribute leads and sync pricing data.
- A portal for employees to enter vacation, sick leave, or other “out of office” requests that will notify their teams, update the HR systems, publish calendar events and even do things like notify the branch office managers to ensure they have a desk waiting for them if they’ll be visiting another branch on their trip.
One day I’ll be writing logic to do financial calculations for our commissions plans, and the next day I’ll be writing network-heavy web API integrations. It can mean a lot of technical context switching, but it keeps me from getting bored!
What are some of the languages you use today and why?
I spend most of my time in the Microsoft stack, so C# is the language I spent the most time writing, with a healthy amount of general web stuff thrown in (HTML, JavaScript, CSS, etc). I like to say I’m a reluctant JavaScript developer — I’m not particularly fond of the language, but Atwood’s Law (“any application that can be written in JavaScript, will eventually be written in JavaScript”) means I can’t get away with not writing some. And, much to the distress of our DBA, I write some marginally questionable SQL too. So, C#, HTML, JS and SQL — I guess that makes me the proverbial “full stack” developer.
I also like to play around with other languages every now and then. I have some hobby IoT projects where I’ll write some python or some C to run on a RaspberryPi or Arduino microcontroller (I’m fond of the Particle Photon devices). I’ve dabbled with R, and even the occasional Java or PHP. I started my career writing C and I expect by the time I retire I’ll be focused on some language that isn’t even on my radar these days, so keeping aware of what’s out there is going to keep me employed long enough to comfortably retire.
What’s your biggest passion these days related to programming?
I love to talk about unit testing and static code analysis. I think as programs get more complex and more abstract, these two groups of tools are what help keep us from making silly mistakes and monumental ones. With unit testing, we can prove that the logic in our programs is sound, and with static analysis we can prove that it’s easy to maintain and free of hidden traps. Or, at least, that’s the potential — there’s still a lot of room to grow.
But the part of the job that I’m most passionate about is creating software that makes people’s lives easier and more fulfilling. That could mean reducing the amount of effort required by our sales ops team to validate and submit commissions payouts to accounting. Or by reducing the frustrations of the accounts receivable team when they are sending out invoices or accepting credit card payments. And, of course, being a part of Stack Overflow and the Stack Exchange network, helping people find answers to their questions and develop their own passions in everything from programming to cooking, photograph to aviation. Hearing from a user or stakeholder that something I wrote made their day easier or more enjoyable is one of the most rewarding aspects of my job.
What still sucks and shouldn’t be in programming?
I’m surprised when I hear about developers that don’t use source control and continuous integration systems. With tools like Git and Jenkins being available for free, and GitHub and TeamCity (which I prefer) being relatively small costs, there’s really no reason to go without. The benefits, even for a one-person team, to having frequent checkpoints in your development cycle, and the ability to easily backup and share that with others, is well worth the almost non-existent monetary and time investments to set up and maintain these systems. And yet, according to the 2018 Stack Overflow developer survey, 19% of professional software developers don’t use a modern source control system!
What are some of the most important skills developers can have?
One of the pitfalls that we professional developers fall into is forgetting that there’s a huge number of developers out in the world that aren’t professional developers. That is, they write code as a hobby, or as a means to assist their job, but it isn’t the main purpose of their day-to-day work. The skills that are most important for someone who’s paid specifically to write code in many cases are different than the skills most important for someone who’s writing code to, say, automate a tedious task or perform complex mathematical computations as part of a research study. Based on the data we see on stackoverflow.com, of the 50 million monthly visitors to Stack Overflow, we estimate only 21 million are professional developers or university-level students.
With that in mind, I would say the most important skill developers can have is writing code that is easily understood by their peers. For a professional developer, that’s other developers on your team or in your company/client. But for many people, that group of peers may not have a lot of programming knowledge. They may need to validate that your program is working correctly, or modify it for new scenarios, so writing code that follows the SOLID principles is just as important. Breaking logic into small, easily understood and well named methods, having classes with single responsibilities, and loose coupling… these are all things that make code easier to maintain and understand. Of course, it also makes them easier to test and validate programmatically, which I’m sure Typemock customers can appreciate.
For professional developers, though, there’s another very important skill that too many lack: the eagerness to understand the business drivers behind the software they write. In my opinion, this is a skill that propels developers careers, possibly even more so than a deep technical skill level. If you want to make a successful career out of getting paid to write code, you have to be able to understand how the people paying you make money and how they justify paying you some of it. Understanding the return that a business gets from their investment in you as developer will help ensure you’re creating the things most important to them — which in turn will raise the value you provide. But it also means you have a better chance of selling the business on the value of your objectives — whether that’s paying down technical debt, refreshing your tech stack, or getting extra budget to attend conferences — if you understand how to frame those things in a way that the business sees as valuable, you’re much more likely to be successful. Moreover, you’re more likely to skip over those projects where you can’t justify them on a business level.
How did you learn about Typemock and what was your first reaction?
I’ve been doing some form of unit testing for well over a decade now and utilizing mocking frameworks for much of that time. But for the most part, I’ve been limited to the various frameworks with no license fees — which primarily work via an inheritance model for .NET. A couple years ago, I decided to start actively speaking at technical conferences and user groups, and I put together a talk on mocking frameworks I called “Mocking .NET without Hurting Its Feelings” that covers both how to use mocking frameworks, and also how they work behind the scenes. I’m a big fan of Roy Osherove‘s book The Art of Unit Testing and knew there was this whole other group of mocking frameworks that weren’t restricted by the rules of inheritance. I set out to learn more about them, with Typemock Isolator being second on that list, behind Microsoft Fakes (which I had access to through my MSDN license). Having played with MSFT Fakes first, I was excited about the power provided by this class of framework, but I really didn’t like the syntax and readability of Fakes. When I got around to trying Typemock, it was like a breath of fresh air. The syntax was much easier to understand and much more intuitive to use.
Do you have tips for readers who are just starting out with Typemock?
Think of automated testing as a type of insurance policy. Similar to how car insurance minimizes your financial risk in the event of a car crash, but requires you to make monthly premium payments to keep your policy — automated tests reduce the risk that your code’s logic doesn’t meet the functional requirements or that a future change introduces a bug, but they also come with the cost of keeping them running. That cost may come as the need to rewrite and update tests as you change your code to meet new requirements, or in the time and effort required to investigate test failures.
If you think about tests in this way, it can help you maintain that balance of risk mitigation vs maintenance cost. If your tests are too coupled to the inner implementations of your code, then your insurance payments will be much higher as you have to frequently modify and rewrite your tests. If your tests are flakey and fail frequently for reasons other than bad code, then your costs to investigate and triage those tests will go up.
To help keep your costs down, while maintaining the risk mitigation you need, be intentional about which tests you keep around. Particularly if you use TDD while writing your code, take a look at your tests and determine if they have long term value, or if they were only useful while writing the code. Could one or two of the tests in a suite give you the coverage you need without the need for the rest? Are they worth the long-term costs associated with keeping them around?
The other tip I would give is that you don’t need 100% test coverage. In fact, I would say that you shouldn’t have 100% coverage. Again, tests are a risk mitigation tool. There’s a lot of code we write that is so simple or boilerplate that the risk of it breaking is very, very low. And more specifically, the risk of it breaking and no one catching it is very low. Of course, this also depends on what the outcome would be if a bug escaped. If the worst-case outcome for a piece of code is that a UI element is slightly out of place, it may not be worth the maintenance cost associated with 100 unit tests for that code. But if you’re writing code for a pacemaker and the worst-case outcome is that someone’s heart could stop and they die — well, then 100 unit tests may not be enough!
Ultimately, be pragmatic. Any amount of testing is better than none, so start small and add tests as you go. But don’t pay for a Lamborghini insurance policy if you drive a Vespa.
How do you convince your manager to write more unit tests or practice TDD?
Assuming you’re a professional software developer, then it’s your job to decide when and how much testing you need. Ultimately, you’re paid to deliver high-quality code that meets the business’s needs. You are, in effect, a craftsman. The person who has commissioned a construction company to build a house doesn’t dictate what brand of hammer they use, or how they measure the length of the framing timbers — they expect the construction crew to use the tools and processes that are appropriate for the job and meet the legal and professional requirements. The same holds true for software developers. If unit tests are what you use to ensure you’re providing a quality work product, then you should be empowered to write those tests. Quite frankly, if your manager has a problem with that, then they don’t necessarily need to know about it — just write the tests and go on about your day. Though I would say if your manager can’t be convinced that unit tests are a part of creating a quality product, then perhaps you need to look for a new manager.
For me, TDD is a personal choice. Some people find writing the tests as you write the code helps them validate the design decisions they’re making as they go along and gives confidence they are heading in the right direction with their implementations. But other people find it gets in their way and is an annoyance or roadblock and would prefer to write tests later in the process. I say — do what’s right for you.
Put another way:
When I paint a wall in my house, I have to put tons of painter’s tape on all the surrounding surfaces to ensure I don’t get paint where it doesn’t belong. But if I hired a professional painter to come to paint the walls, often they are so skilled with their brush that they don’t need to put up any tape — they are able to create a perfect edge with just the side of their brush. For them, putting up tape would slow them down and likely cause them to create a lower quality product.
TDD is a tool available to you in the same way the painter’s tape is a tool for painters. Try it for a couple months and if it’s not something you see becoming a useful tool for you (given enough practice and time), then TDD is just not the right tool for you and you can write your tests at some other point in the development process.
What are some of your must-have tools or libraries that you use in your daily working life?
Well, there’s the obvious stuff, like a quality code editor (for me: Visual Studio or Visual Studio Code), some sort of static analyzer (ReSharper, CodeRush, SonarQube, etc), and a solid build and test environment.
For me, there’s another tool I find key: An easy-to-use screen capture/video capture utility. When it comes to communicating ideas, or explaining how things are/aren’t working, a picture is worth a thousand words. So having a screen capture utility that you can quickly capture and annotate parts of your screen goes a long way. Personally, I use TechSmith’s SnagIt, though there are plenty of options out there for free.
When you need a quick recess at work to regain focus, what do you do?
While I was working in downtown Chicago, I would take a 5 or 10-minute walk around the block in the summer season or around the hallways in the cold of winter. But now that I work full time from my home, I’ll sometimes take a walk, or do laundry or tidy my office — some sort of mindless task where I can let my mind wander a bit and just step away from the screen. If I find myself mentally obsessing on something that I can’t break out of, I’ll usually jump on Twitter for a few minutes and maybe read a blog post or two to force my mind to think about something else.
What’s your horror/war story from the coding trenches?
One of the services my first employer provided was public WiFi at that big coffee company you see on just about every street in the US. Back then, you had to pay for coffee shop WiFi, but we had a feature where you could purchase 12-hours of WiFi in one store, then walk down the block to another store and continue using your purchased session.
Well, there was a bug that was preventing some people from continuing their session when they moved to another location and I was tasked with fixing that bug. I found the issue in our access control logic and fixed it, tested it, pushed it out to production, and gave myself a pat on the back for a job well done. Three days later, we discover that large groups of people are now getting free WiFi at all locations. It turned out, when I fixed the bug, it opened up a code path to another bigger and nastier bug in the another part of the system. When I did my testing, I was stopping short of the other bug, so I didn’t catch it. The company ended up having to pay a 5-digit penalty to cover lost revenues for those three days and I learned a couple valuable lessons:
- You can’t rely on unit-level testing alone. System-level (or integration) tests are important to make sure all of the moving parts work when they’re put together. That’s true for automated testing and manual testing alike.
- Failures happen and companies that provide a culture where it’s safe to fail (so long as you learn from that failure and it wasn’t malicious) will foster, attract, and retain some of the most talented people in the industry.
What’s the best advice you’ve ever received or what advice would you give your younger self?
As I took on more leadership responsibilities early in my career, one of my first managers, Dr. Jim Keeler, gave me some advice that I still utilize almost 20 years later. I have a tendency to be a perfectionist and want to make sure that everything under my area of responsibility goes well. But there are times when things aren’t going smoothly and chaos can seem like the norm. In those times, I would end up working nights and weekends to try to keep all the balls I was juggling from being dropped, but it was wearing me down. Jim told me that it’s ok to let things drop now and then. Sometimes, you have to let things visibly crash in order for the right people to know it’s broken — and only then will you get the help needed to lighten your load. The idea of letting something under my responsibility fail is frightening, but if that’s what it takes for stakeholders to know that things are broken, then it may be the right thing to do. Granted, you should do your best to prevent things from getting to that point, but life happens, and especially at high-growth companies, there can be so much going on that “small problems” don’t get addressed until they become “big problems”. So let them fail (in a safe way), so that it can get the attention it deserves.
What are some interesting links you can share about yourself?
I’m on Twitter way too much, so you can find me there as @Wright2Tweet. My website, including my blog, is at https://wrightfully.com. Between the two, you can find out what I’m doing, thinking about, traveling to, or just ranting over. If you want even more, the front page of my website includes links to my various other homes on the ‘net.
What is one question that we should have asked, and we didn’t and what would be the answer?
What got you interested in speaking at technical conferences and user groups?
Throughout my career, I’ve benefited from the guidance, mentorship, and assistance from others in the field with more experience and knowledge than me. I’ve tried to “pay it forward” by helping others where I can: submitting to Open Source projects, blogging on topics I have experience with, and helping behind the scenes to run some conferences and user groups. I struggle with anxiety and public speaking was always just too scary for me to even consider. A couple of years ago, I was attending the That Conference technical conference in Wisconsin and was particularly inspired by some of the speakers there, as well as another attendee, Steve Hicks, who held a small group discussion for people looking to get started in speaking. Soon after, Steve started speaking at several events and I committed to overcoming my fears and doing it as well. I’m very glad I did, because it’s allowed me to reach a new audience and meet some amazing people from around the world.
