Optimism and Pessimism

My dad is an engineer. Looking back, there was a dominant engineering atmosphere and attitude in our house. Of course, I didn’t know that, to me it was just normal. But my wife, who does not come from an engineering family, noticed it right away. It’s not all bad, nor is it all good, it’s just different.  But I do remember hearing laments about how if there weren’t sales people, life would be a lot easier (a sentiment I no doubt have uttered at times as well.)

When I was 21, I was doing an extended internship and we were talking about some problem. I made some comment like “No way is that going to happen.” My boss and the others looked at me and said “You’re way too young to be that cynical.” I then explained that my dad was an engineer and they all responded with “Oh, well, that makes sense then.”

As I started my career, I was fairly pessimistic. I was no Debbie Downer, but I often doubted that timelines would be met, or that what our internal customers said they wanted was actually what they wanted. As I worked with more engineers, I saw that this was a common trend. We’d been burned in the past, and it had jaded us.  As a group, in my opinion, we were pessimists.

But every once in a while, I’d come across someone who would say something like “I can do that in an hour. It won’t take long.” And I thought, “Wow, this guy must be a lot better than I am because that would take me a 1/2 day by the time I got all the way through it.”  So my worldview began to change, maybe there were optimistic engineers. However, they seemed to be few and far between.

It wasn’t until this past year that I was able to reconcile the predominance of pessimistic engineers with the occasional, or even often, optimistic engineers.  As a team lead, I’ve spent less time coding in the past year and more time clearing obstacles from my team, among other tasks. This has lead me to observing the team dynamics more than I ever have, and I’ve come to this conclusion: Software engineers are long term pessimists, but short term optimists.

What do I mean by that? If you ask a software engineer how likely it is that they’ll meet a deadline that is 6-8 months in the future, you’re going to get responses like “It’s possible”, “Maybe”, “Not likely”, “It depends” or even “No way”, and “I doubt it.”  But ask those same engineers how hard the next story in the backlog is and you’ll hear things like “I should have that in PR today”, “I can overhaul that module in a week”, “Doesn’t look too bad.”

In the end, if you don’t recognize these differences, it’s going to cause confusion and frustration. For example, if you base your project health only on what the team is doing next, you’ll think “This is great, we’ll be done 3 months ahead of schedule.”  However, if you base your sprint progress off of long term estimates, you might be left wondering if there will be anything to demo at the end of the sprint.

The Importance of Culture

This past week I had two separate incidents while out shopping. The first was at Menards, a home improvement store. I was buying several different items including 4 concrete pavers. They were plain, 12″x12″ blocks.  They didn’t have a UPC on them anywhere so when I went through the checkout the cashier had to look them up in a book. His supervisor told him they wouldn’t be in there because they were new. So he turned to his register and started looking up 12″ cement blocks and several other terms. I told him that they were $1.47 each.  He murmured something about looking that up.  His supervisor went over to the customer service desk and started looking.  About 5 minutes later, I’m not exaggerating, I’m still standing there. I tell his supervisor they were $1.47 each, she said they couldn’t look it up that way. They eventually found something and charged me the right amount and I was on my way. I came really close to just telling them to forget the blocks, but I needed them for a project I was working on.

The next day I was at Costco. I was checking out and the cashier told me it was time to renew. However, I had been in about 3 weeks earlier and already renewed.  He called his supervisor up. She put in a code that let him ring me up while she went to go investigate.  I was able to complete my order before she found out any information. About 30s later she told me that she didn’t have the ability to see the information and I needed to talk to member services, so I took my cart full of groceries over there. Within about 5 minutes they had found the mistake and fixed it and I was all good to go.

In the first case, the employees weren’t really empowered or equipped to solve the problem.  I felt bad for the cashier and his supervisor as they scrolled through a long list of landscaping brick descriptions looking for one that resembled “12×12 plain”.  But that’s all they could do. They could not do a price override or offer any other remedy to the situation. It was very much brute force: We’ll find the right price and charge you that. To make matters worse, there was a couple behind me in line this entire time. They were trapped.

In the second case, the cashier and his supervisor were allowed to ring up my order and solve the problem of renewal afterwards. This was great for me as I didn’t have to get in multiple lines just to get my groceries. It also worked out for the people behind me in line as they weren’t trapped in a line while some bozo (me) ahead of them argued about his renewal.

The difference in culture was subtle but clear. It highlighted to me how important culture is. Not just in retail either. Lots of companies operate more in line with what I experienced at Menards.  Individual employees aren’t allowed to make critical decisions. They’re forced to use systems that someone else has put in to place (often that person will never use the system either.) They have to just brute force things as well.

However, other companies not only allow, but actually encourage their employees to make decisions, to speak up and try to solve problems.At Aviture, the company I work at, we tell people in interviews “We hire adults and we expect them to act like adults.”  This has several meanings. Some of the obvious ones are to be accountable to your team. Don’t just “flake out” and not show up one day, but communicate with your team. If you need to take a day off, take it, but let people know. But more than that it means that we’re going to treat you like an adult, and not a chid. So if you have an idea, try it out. Be willing to take calculated risks, take chances, don’t be afraid of failure.

That attitude contributes to a lot of our innovation. And it’s true at lots of places, not just Aviture. When employees are treated like they’re smart and care about the company and the customer, they’ll typically perform better than if they’re treated like they have to be constantly monitored and constrained.

Your Users Aren’t Rational… And Neither Are You

The very first time I wrote an entire application in .NET, I was working to convert a VB6 application. It was a sales tool that had evolved over time. Years before I started on it, it was a couple of equations until it grew and grew. By the time I got there, it could connect to an ERP system and get the actual prices and lead times on parts.  Both internal and external sales people depended on this application to do their job.  I worked on this application for quite a while. At one point, about 12-18 months into the project one of the sales managers was looking at it. This was a man that didn’t use the software very much. Every once in a while, he’d need to fire it up to look up something for a customer.  He was so used to the previous version that the first thing he said was “Where’s the next button?”  The previous application had a next button to move from one tab group to another.  In discussions about the UI we decided we didn’t need that functionality any more in the new version. Yet at the very first use by this person he asked for that functionality.  I tried to explain why the next button was no longer there, the internal sales manager (who I’d had numerous discussions with) tried to explain why it was no longer there. But it didn’t matter. In his mind, if there was no next button, he didn’t feel like he could generate a quote.

It actually got to the point that when I left the company, I received a physical push button that the internal sales manager had labeled “Next.”  That button sits on my desk today, 3 jobs later. It’s there as a reminder.  It reminds me that sometimes the customer “just wants” something, and that’s ok. After all, most of the the time, I’m writing software for someone else to use. In the case of this sales application, it was a large part of their day to use this software.

I know it can be very frustrating to deal with these situations. After all, as developers, we’re paid to solve problems. We’re paid to know about practices of how people use an application. So when we present something to users, it’s not done absentmindedly. It’s done because in our professional opinion, it’s the best option. Much like people trust a doctor’s or lawyer’s “professional opinion”, developers expect their opinion to be trusted. When it’s not, we often start to think that our users are irrational.

For example, on that same project, we introduced a new paradigm. Before a quote was started, the type of quote had to be selected. These were usually things like the type of industry the quote was for, or the application that it was going to be used for. The intention of this was that we could do some data analytics on the application, such as “How many quotes did we do for industry X?”  But we also did it so we could start setting some smart defaults for specific industries.  For example, some industries needed copper instead of aluminum because of the environment that it was to be installed in.  We were trying to have the application provide more data instead of requiring the user to always know that.  But what was the first thing that the users said when they saw it?  They said “Why do I have to click here to select this application? I didn’t use to have to do that? Now it takes me 3 clicks to start a quote, it used to only take me 2.”

To me, that was irrational. The clicks weren’t added for the sake of adding clicks, but instead to provide value to the customer, but they weren’t seeing that.

What I realized later in my career, however, is that for as much as irrationality annoys us as developers, we’re often just as guilty.  It doesn’t always show in how developers use applications, but often in how things are done.  Two areas that jump to my mind when I think about this is TDD and Pair Programming.

Both of these disciplines have some very passionate adopters. Developers that do TDD and developers that routinely pair program can easily talk about the benefits of each practice. For example, I’ve given no less than 3 separate conference talks on TDD, and it was my first Pluralsight course as well. Since I’ve started consistently doing TDD, I’ve seen so many benefits. When I talk to people about TDD a lot of them (most?) even assent to what I tell them. But when it comes to writing code, very few people ever make that shift and start doing TDD. It happens for a variety of reasons. They’re afraid it will take too much time, or they tried it once and ran into a problem with testing certain parts of code, or they’ve always just sat down and started writing etc. On the one hand, they’ll often say “I agree that the things TDD gets you are good” while at the same time saying “But I’m not going to do it.”

I think the same can be said about pair programming. In fact, I know it can, because it dawned on me this week that I don’t really want to pair program with someone despite the fact that numerous people practice pair programming and can tell me all about its benefits.  Why don’t I want to do pair programming?  For a variety of reasons.  First, what if I want to take a small break and my pair doesn’t, so I want to be looking at reddit, or checking email, but I’m pairing with someone so I can’t. Secondly, what if the person I’m pairing with is way smarter than me? Are they going to be sitting there judging the code I write? Constantly thinking to themselves of better ways to write the code? What if the person I’m pairing with doesn’t write clean code? Am I just going to be a constant nag for things like better variable names?

You see, my reasons for not pairing have nothing to do with how effective pair programming is. It’s not that I think I can write code quicker without a pair. It’s not that I think I’ll have fewer errors if I just do it myself. It’s none of that. It’s simply that “I don’t want to.”

If we’re honest with ourselves, we’ll realize that both developers and users are part of a larger, irrational group of beings. That group has a name, and it’s called “humans.”  Once I started realizing that, I started being able to work with customers. They stopped frustrating me so much. And that’s important. A developer has to be able to work with customers without constantly getting mad or frustrated, and the burden is on me, not my customers.

Why TypeScript?

This weekend I watched a talk about TypeScript at Nebraska.Code().  The presenter seemed to have a good grasp of TypeScript and was a good presenter.  Sadly, that combination doesn’t always happen.

One thing I was glad about, was that he put up a picture like this:

I immediately thought, “This is going to be good!” as I figuratively rolled my eyes. But instead, he said “This is NOT the problem with JavaScript.”  That comment immediately made me realize that this was going to be a talk that wasn’t going to just bash JavaScript.

And to be fair, he did.  He identified the following problems with JavaScript:

  • No type safety
  • Functional language with inconvenient syntax
  • Object base, not object oriented
  • Few organizational constructs

He then offered the following reasons as to how TypeScript helps:

  • Optional static typing
  • Familiar OO constructs
  • Enhanced functional experience
  • Improved code organization
  • Works w/ existing JS libraries

The impression that I left the talk with was “TypeScript makes JavaScript object oriented.”  The speaker never said this, and I don’t think he even tried to imply it, so it might just be a combination of everything else I’ve heard about TypeScript coming to a head.

After watching this talk, I’m still not convinced that TypeScript is the way to go.  I like ObjectOriented programming. The bulk of my career has been using OO principles (C++ and C#.)  But I’m of the mindset that not every language has to be object oriented. After all, C is not object oriented and it definitely serves a purpose.  That doesn’t make C a bad language. Just as Haskell isn’t a bad language. Just because they are not object oriented. Are they possibly harder to learn? Maybe, or maybe they’re harder to learn only because we’re so used to OOP.

I’m reminded of when I was in seminary. I took 15 hours of Greek and 15 hours of Hebrew. I started with the Greek classes, and they were way easier than Hebrew was.  I had a smart friend who started with Hebrew and he really struggled with Greek. To me, it was strange, because Greek was so much easier to me.  The problem was, he was coming from a different paradigm, a good grasp of Hebrew, to a new paradigm, koine Greek.

I think the same thing is true with programming languages. JavaScript has some problems (tell me a language that doesn’t.) But I don’t think one of it’s major problems is that it’s not OO. I’m also not convinced that it having dynamic typing is necessarily a bad thing either.  However, approaching JavaScript as if it WAS an OO language or that it HAD static typing is going to cause you problems.  In the same way as taking an English sentence and translating it word for word into Spanish is going to sound off or “wrong” to Spanish speakers (if for no other reason that the differences in word order.)

The best example, to me, from the talk about why TypeScript is beneficial was the example of inheritance. For this example, he demonstrated a relationship like “A developer is a type of employee.”  For us OOP folks, we immediately get that. But it’s different in JavaScript because it’s a prototypical inheritance. TypeScript cleaned up that type of inheritance with no problem. The TS code was much smaller and easier to read than the generated JS code. The speaker even commented that in 6 months, when he has to come back and make a change, he’d rather make a change on the TS code than the JS code.  The JS code had 3 or 4 levels of nested functions.  By and large, I would agree. If those were my only two options.  But I feel like that type of solution is missing something.

If someone came to me and described a problem domain with highly related entities, for example, the classical Animal:Mammal:Human hierarchy that is used so often in OOP, my first thought would not be “I know, let’s use JavaScript to model this.”  In the same way that I would not think “I know, let’s use MongoDB to store it.” I guess what I’m saying is, while TS seems to clean up inheritance, a possibly better way(?) would be to use a different language.

And I think that is my biggest struggle with TS. I get that they’re trying to make JS better, much like C++ tried to make C better (and arguably that C# tried to make C++ better.) But the difference to me is that C++ doesn’t compile to C. It’s a different language that generates its own binaries.  I think if TypeScript had native browser support like JavaScript, I would be more prone to adopting it.  But even then, only if it was its own independent language.

Those are just my thoughts. I’ll still keep reading & listening to stuff about TypeScript. I’m sure at some point, I’ll try to write a Hello World type of application. But it’s still further down the list of things to learn for me.

How Do You Use Pull-Requests?

The process on our team is to create a feature branch off of develop, do your work and then push it up to the repo. Then when it’s all done, you create a PR and have someone from the team be the “primary reviewer.”  This person’s job is to review the PR, make sure that you’re doing the right things in the right way, then they have to pull down the branch and test it before they can approve it.

We got to this point after many iterations about how we wanted to do PRs. At first we opened up all the PRs to everyone on the team and after a majority of the people approved it, we would merge it in. Then we found that a lot of people didn’t want to review and the PR process would drag on. Having a PR open for a long time causes its own problems, as by the time the code is ready to get merged, it’s old and often has a lot more conflicts.

Next we tried to only have a couple people PR the code, the “leads” if you will.  However, that didn’t work out very well, as people would often forget to address the comments etc.

We tried PR buddies, and finally came to this incantation.  Despite all the struggles of PRs, everyone on the team seemed to agree that they served an important purpose, and wanted to continue them.

Recently, however, I had a revelation about PRs. I always approached PRs as “Let me review this code to make sure it meets our standards, and is clean and working.”  That would be my motivation, and sometimes I felt like “I just don’t have time to do this PR because I have my own stuff to do.” But then, within the last couple weeks, something dawned on me.  A PR is not just a way for me to make sure other people on the team are doing things the right way (and for them to make sure I’m doing them the right way) it’s also an opportunity for me to learn.

When I open up someone else’s PR, I get a chance to see how they tackled the problem, or how they solved something. Sometimes that’s as simple as seeing them use some new lodash function that I’ve never seen. Other times, it’s seeing a different paradigm or approach to the code. Still, other times, it’s seeing something like a new way to test the code.

I’m a big proponent of writing clean code because I believe that we’ll read our code many more times than we’ll write it.  But it never occurred to me that the first time I’ll read that code is in a PR.  I’d like to say that since I had that revelation, every PR has been walking in the light, but it hasn’t.  I still find myself, at times, looking more to make sure that the code meets the team standards, and forgetting completely that I have a chance to learn.

If your team does PRs, I’d highly recommend trying to take the approach of learning something from a PR, instead of simply judging it.

We Are Learners

I try to not mix my 2 blogs. I have this one, that focuses on the professional side of software development, and I have another blog which follows my Brazilian Jiu Jitsu addiction. The reason is, most of the people interested in software don’t practice BJJ, and most people that practice BJJ don’t care about software.  That said, my worlds collided this week.  I was listening to a podcast, where the head blackbelt at our academy was talking about when he was young. He’d gone out and won a big tournament. He came back to the gym, and told his professor (BJJ term for head instructor) something to the effect of “There’s nobody here for me to train with. I’m better than these guys, I just won this tournament.”  He spent the next hour in the middle of the mat as any and every person at the gym had free reign against him.  The other students were promised advancement for every time they could make my professor submit.  He had one guy ultimately choke him until he passed out. When he came to, he was told that even though he was in his 20s and his opponent was in his 60s, his opponent was a blackbelt in Judo and had been practicing for quite some time.  On the podcast he explained “That’s when I learned that you don’t fight the guy, and you don’t fight the belt, you fight the position.”  Meaning, regardless of who is attacking you, in BJJ, you have to be smart and defend the position. He learned something that he wasn’t planning on learning. He wanted to train with people who could teach him new moves and new techniques. In the end, he learned something much more valuable.

How does this apply to software development? Developers, as a group, tend to enjoy learning. At this point in development history, how could you not enjoy learning? There are new frameworks and libraries being produced by the day (by the hour?) Things are constantly changing. Whether it is new languages, new paradigms, or just improvements in the ones you’re familiar with, there’s always an an opportunity to learn. It’s something that I think drives most of us to fire up our computer every day.

But not all the learning as professional software developers is about what a particular framework can do. The past month or so has been a tiring month on my project for many reasons. Not bad, just tiring. This past week in a developer meeting, I encouraged my team to use these opportunities to learn and grow. We’re using Angular, which is something nobody had extensive experience with before this project, so there’s a chance to grow in that framework. But even more than that, we’re interacting with a domain that none of us have experience with. We’re performing tasks for a client that none of us of have worked with in the past. We have the chance to learn specifically about the domain and about the client. However, we also have a chance to learn about clients in general. How do you handle client expectations? What’s the best way to find out use cases for a system? How do we determine priority based on client feedback (hint: a client will almost never tell you “Do A, then B, then C” so you have to learn to listen and understand what they’re after.)

A lot of things might be considered boring or even “not real work” (which is a phrase that my Project Manager hears me jokingly say way too often.)  But there is not a software project that exists for paying customers that doesn’t have to solve these problems. So we have to spend time & energy learning about them as well. Being a developer doesn’t just mean learning how to program, it means learning what to program as well as when and why to program as well. So even on projects that don’t see technically challenging, there is always more to learn.

After talking about that with my team this week, I came home to a broken toilet. Thankfully, my brother-in-law used to be a plumber, so he tried to help us fix it over the phone. We finally realized the jet at the base of the bowl was clogged, most likely with one of those toilet cleaning tabs.  I didn’t set out the day to learn about toilets, but in the end, learning that 1. they have a jet at the base of the bowl and 2. that if it is clogged, the rest of the unit won’t function turned out to be rewarding as well.

What’s the Point?

For me, this past week was filled with meetings. I had meetings with the client, I had a demo, I had sprint planning, I had a meeting or two on our project plan. I even had a couple meetings with the purpose of helping the people who will be meeting with the client be prepared. In the end, I had about 8 hours of meetings this week. Those are the ones on my calendar. They don’t count the times I had “discussions” with anyone on my team. I spent a lot of time not in my IDE this week.

All those meetings and interactions led to very little time of dedicated development. By that, I mean there wasn’t one day that I had a good 4 hours of uninterrupted development time. Yet I was still able to release two new features this week. I started thinking about how I was able to do that. Study after study shows that switching contexts is expensive, and I can attest that is true, but I was still able to be productive and help move my project forward, not just with designs & client relations, but the product today is better than it was on Monday in part because of the software I wrote.

As I started thinking about it, I examined my motivation and what drives my software development. So my number one goal is “Does this move the project forward?”  Not “Is this a good change” but rather, is it moving the project in the right direction.  Which then lead me to think “HOW do I move the project forward?” The answer to that question was actually surprisingly easy “By completing this story that is in front of me right now.”

However, the question “HOW do I complete this story?” is a bit more complicated. Any story has a lot of possibilities for rabbit trails and diversions. When I sit down to complete this story I could just ignore everything in the project and slap something together. At the other end of the spectrum, I could take time an evaluate the entire project and figure out how make refactorings and then write my project. As is often the case, the truth is probably somewhere in the middle. As I’m working on the story, I’m still asking myself the question “Is THIS moving the entire project forward?” If I can’t honestly answer that question yes with at least a 95% certainty, I don’t do it. Does that mean sometimes I don’t make changes that would be “good”? Yes, it does. But the point is for me to move the project forward.

I think some people that know me and how I write software might be shocked by me saying this. I’m a HUGE proponent of TDD (if you’ve read this blog at all, you probably already know that.) I’m also a fan of clean code and refactoring code. One friend also ribs me about the amount of joy I get out of deleting code (seriously, it’s better than writing code!)

So how can I be such a huge proponent of these aspects of software development that are often viewed as rearranging deck chairs, and at the same time talk about the number one goal of any software development needs to be “to move the project forward?” Simple. I do TDD, refactoring, clean code etc because those help me move the project forward as fast as possible.

There’s a lot of things we can do as software developers. There’s all sorts of practices and patterns that we can implement. But at the end of the day, the customer doesn’t care about the repository pattern, or observer pattern. Often times, they won’t even understand what that is, nor should they. What the customer does care about is a quality working application.

So for me, the point of software development is to deliver a working application. If in the midst of development I’m doing something that does not meet that goal, I stop.

Code Optimization

For starters, a friend reached out to me on Facebook and asked for my thoughts on optimizing code, especially with the cost of hardware being so cheap. I don’t know that this will answer his question, but it’s my thoughts on the subject.

Early Optimization

Premature optimization is the root of all evil (or at least most of it) in programming. – Donald Knuth

That is a rather famous quote that developers use quite often. A lot of times it’s used as an excuse for writing bad code, sometimes, it’s used to remind people to not spend time optimizing their code too early.

Too often developers will spend time and energy trying to lay out the perfect design and perfect implementation because they fear an area of the application will be too slow. Keep in mind, they haven’t tested the performance. They don’t know that it’s a bottleneck, just a hunch that it will cause a problem.  The reason this is bad is that in isolation it’s difficult to tell what will be slow code.  For example, if you’re reading through code and you see something that raises a red flag, you could take some amount of time to resolve that issue. Only after resolving the issue and getting it merged into mainline development do you realize the code you just optimized gets executed one time a week, or a month, or a year. Meanwhile, there is code in the application that gets executed multiple times a minute, or even multiple times a second.  Until you know what the actual bottleneck in the application is, it is irresponsible to try to optimize it.


That’s the first problem with code optimization. At the other end of the spectrum is a different problem with code optimization. A lot of times this problem starts with a discussion like “Space is cheap” or “RAM is cheap” etc. The thought is, that developers get paid a lot of money. Most of the time a senior developer in the mid-west is making around $50 per hour. However, the total cost of development is usually closer to $75 per hour. And if you’re a consultant, you’re probably getting billed out at $100-150 per hour.  So it doesn’t take a lot of time before the cost of implementation gets pretty high.  For example, instead of paying a developer 10 hours, you could buy a pretty decent server, and the developer could be doing other things.

However, this makes a couple assumptions. First, it is assuming that RAM and CPU solve the problems developers are trying to solve. Sure, RAM and CPU help a lot, and they cover over a multitude of [programming] sins. But they’re not the only systems that could be bottlenecks. For example, network throughput could be a bottleneck. This could happen if an application is sending too much unnecessary data. Instead of sending only the data that is required (e.g. 100 bytes) a developer may send an entire record, 1KB, or 10 times more data than is required. This isn’t solved by building a bigger or faster server. It’s only “solved” by either expanding the network pipe, or by sending less data.

The second assumption this mentality has, is that if a developer delegates performance to a server, that the rest of the code will not have problems. In fact, it’s probably just the opposite. A developer that takes such a lackadaisical attitude to performance, probably isn’t writing good code anyway.


While typing this up, I kept thinking about one of the first articles I ever read about Map-Reduce years ago. It discussed how Google used commodity hardware to implement their blazing fast speeds. They did that so that if one of their servers dies, they can easily, quickly (and cheaply) pull the server out of the rack, and throw a new one in and keep running. They did this, not by stock piling a lot of really expensive servers. Instead, they did it by writing code that is optimized for the hardware they had. They wrote frameworks and libraries that realized the bottleneck was serially processing a request when delegating it would be much quicker. It wasn’t that the hardware they had was bad, and couldn’t process a million records, it was that it couldn’t easily process billions of records. However, they realized that if they took those billion records and split them up across 1000 computers, then each of those 1000 computers could easily process a million records.

That is, they matched up the code being written to optimize the hardware they had available. They didn’t buy bigger servers, or more CPU. Instead, they wrote good code to take advantage of what is there.

I will most likely never work on a Map-Reduce algorithm, much less one that will be used by such a large company & most people on the face of the earth. However, that doesn’t excuse me from the responsibility of writing smart software. The application I’m working on right now will be run on a corporate network that I have absolutely no control over. I can’t dictate what the specs of the users’ computers are, nor can I dictate when they should be updated, or even what OS version they’re running.

If I were to divest myself of the responsibility and say “When they upgrade, it will be faster” I’m opening myself up to bad coding practices, and building something that might take an inordinate amount of hardware in order to perform.

Your App Might be Making Your Users Fat

In his book The Power of Habit, author Charles Duhig recounts a series of studies that were done around people’s willpower. Researchers were trying to find out if willpower is like a muscle, something that can be trained. In one experiment, participants were told they were doing research on taste profiles. They were brought into a room and were presented 2 bowls, one had radishes and the other had warm chocolate chip cookies. Each participant was told to only eat out of a particular bowl. That is, each participant could only eat radishes or cookies, and it was determined by the researchers.

After a period of time, the research assistant would come back in and tell the participant that they had to wait about 15 minutes for the next part of the experiment.  In the mean time they were presented with a puzzle and were told to work on it until either they got frustrated and rang a bell, or until the researcher came back in. However, this was not an activity while they were waiting, this was actually the next step in the experiment. The puzzle was literally impossible to solve. Those people who were only allowed to eat radishes spent much less time working on the puzzle before ringing the bell. Additionally, they displayed a much more negative attitude when working on the puzzle, berating themselves for messing up etc.

What the researchers found through this experiment, and others like it, was that willpower is a diminishing resource. That is, the willpower the radish eaters exhibited in passing up the cookies was the same willpower they needed to keep working on the test. Conversely, the willpower the cookie eaters saved by not resisting temptation came in handy when working on the puzzle.

It’s the same reason people tell you to work out early in the morning. By the time you get through a day of decision making and stress at work, you don’t want to go to the gym, you want to go home and relax in front of the TV. If you’re like most people, you don’t even want to go home and cook, you’ll pick something up along the way.

If you think about it, it’s a contributing factor to why diets fail around Thanksgiving and Christmas every year. People have every intention, but as they travel and spend more time with family, stress levels rise (if my family is reading this, not you, obviously, I’m talking about other people.) The stress and little decisions that go into the day of dealing with aunts and uncles and cousins and in-laws and brothers and sisters depletes your willpower and ability to turn down that extra dessert.

So how does this relate to software and your app? Think about the experience your average user has. Are you asking for more information than you really need? For example, if I specify my zipcode, you should be able to know my city. Or if I type in the first 2 digits of my credit card, you should know what type it is without asking me.  Those two are very trivial examples, but the represent two times I have to think & decide “Is it a Visa or Mastercard?”

If your application is presenting your users with a lot of choices, and is not guiding them through the process, you are depleting their willpower, just by using an app.

Wouldn’t it be nice if instead of depleting their resources, we could conserve them? I think we can, but it will take more effort on our role as developers and designers. Try to find a way to guide them through the information you need instead of prompting them with decision after decision.

“What did you learn at the conference?”

This past weekend, I spoke at St. Louis Days of .NET. It was my second time attending and also my second time speaking there. It’s a great conference. I enjoy the location and the people.  The drive isn’t always fun, but this year my wife & kids came along, so that was nice.

As we were leaving the conference and heading home yesterday, my wife & I started talking about how I hate when people ask me what I learned at a conference. I dislike it because it’s rarely something I learned in a particular session. For example, I watched a session on Ember. It was good, the presenter was engaging & energetic. He knew is information, but by-and-large, I didn’t really learn anything I didn’t already know about EmberJS. And that’s ok.

did learn about the audit tab in Chrome dev tools. I also learned how Hadoop got it’s name.  I learned a couple other bits of trivia, we’ll say, at the conference. But to me, it’s not about the sessions necessarily.

I spent 2 days with people that love technology. I hung out with people that are passionate, not only about coding, but about helping other people get better at coding. I was able to “network” with a lot of people. And that was great. I now have connections to more people which lets me see more of what is going on in the industry.

The best part about the networking is that you don’t have to be a speaker to do it. I spent about 30 minutes in the speaker room this time. During that time, I was IMing my team back home asking them how their PRs were going and looking at some things in code.  Once that was done, I left (and that was in part due to the political discussion going on in the speakers room.)  The night before, when I hung out with the speakers at the speaker party, I stayed pretty much with people I already knew.

My point is, speakers are just like everyone else. Even the guys that have a full room or standing room only are more than eager to talk to you. It’s why we do this, we love talking about technology.

So what did I learn? I don’t quite know yet, ask me again in 8-10 months once I get a better feel for how my network grew & changed this weekend.