Fatigue & Identity

One of the trends in development recently has been to talk about fatigue. As far as I know, it started with JavaScript fatigue. The idea being that JS is changing so much and so often that people can become exhausted trying to keep up.  A mere 2.5 years ago, when I started at my current job, Backbone and Marionette were pretty cutting edge here in the mid-west. There weren’t a lot of people doing them, and even fewer doing them on production applications.  In that time, I’ve seen Marionette, Angular, some Knockout, Dart, and Typescript. Now we’re seeing things like Elm and React. All of this to be able to have a rich UI on the web. And those are just the languages. That’s not even talking about things like Grunt, Gulp, Webpack, Browserfy, RequireJS, etc.

The fatigue sets in when developers try to figure out how to stay up to date with technology. Just when you think you’re getting good at Marionette, Angular comes out. You have a grasp on Angular, and they overhaul it with Angular 2. The thought is, “How can I have time to learn the next framework before it’s obsolete.”  This typically then leads to developers longing for the days of when libraries only changed once a year or so (or less, if you were waiting to upgrade from .Net 2 to .Net 3.)

I personally haven’t felt much fatigue. I might even be described as JavaScript apathetic. (Or possibly as having fatigue fatigue…I’m tired of being tired.) And I really enjoy writing JavaScript.

So I started thinking recently, why don’t I suffer from JavaScript fatigue? Is it because I’m far superior to all these developers who experience JavaScript fatigue? I seriously doubt that. Is it because I’m too old to care? That’s possible, but while I might be nearing ancient in the JavaScript world, I’m not that old.

Then I started thinking of something I started learning around 10 years ago, and that is, what is my identity?

If my main identity is a developer, I might experience some fatigue as I see how quickly the industry is changing. If I identify primarily as a JavaScript developer, I probably have more fatigue than just being a developer. If I find my identity in being an Angular developer, then I’m probably freaking out and suffering a lot of fatigue because I don’t know if I should learn Angular 2 or React next. Has everything I’ve done the last two years been a lie?

But my ultimate identity is not in any of these things. Yes, I’ve just wrapped up an app that was written using Angular. I’ve been doing JavaScript applications for about 2.5 years, and I’ve been a professional developer for almost 16 years. But that’s not who I am.

So who am I? Where do I find my core identity? My identity is wrapped up in being a child of God. When I’m anxious, I remind myself of Romans 8.33 “Who shall bring any charge against God’s elect? It is God who justifies” (ESV).  If I’m a child of God then everything else comes in a distant second place. What JavaScript library I’m going to be using next week is one of the least of my worries.

This was one of the biggest & most important things I learned during my time in seminary. My identity impacts so much of what concerns me and how I’m able to handle things like JavaScript fatigue.

Air Filters & Clean Code

This weekend I took my wife’s truck in to get some new tires. While at the store, they did a multi-point inspection. They called me to tell me I needed a new air filter. I turned down their offer to replace it (they wanted $50.)  Today, we were driving and her “Check Engine” light came on.  I took it by the parts store to have them run the code. The code indicated it could be one of a few things, the easiest thing to do was to replace the air filter. So I bought the $13 air filter and came home to replace it.  When I popped the hood to replace the filter, I saw a hose that runs off the main hose from the air filter, and it had popped out of its connector. It’s most likely that the loose hose caused the problem, although it did need a new air filter.

As I thought about this, I thought it was a good illustration for clean code.


The only way to know if an air filter is dirty and needs replacement is to look at it. (At least in the type of cars I buy. Maybe in the high end cars there’s a sensor that tells you, but not in ours.) To do this, you have to take the cover off the filter, move a couple hoses around, pull out the filter and see if it’s dirty.

What happens when you need to fix a bug or add a feature in the code?  You have to read the code that’s already there. Imagine that the code you have is like my wife’s car. In order to really get at what it’s doing, you have to dive into functions and look at each one until you know what’s going on.  You finally diagnose the problem and put in code to fix it. But, like with my wife’s car, you knocked loose a hose or two.  You don’t notice it right away because the code isn’t that clean. It’s hard to read. But a day or two after release you start seeing things in production that don’t look right.

When you pop the hood (i.e. go through the source control history) you see you accidentally deleted a line of code that was necessary.

Now, imagine your code was clean and readable. You have tests that tell you what is happening (and with some analysis, what isn’t happening.)  You’d be able to jump in and implement the right fix pretty easily.

It would be like if my wife’s truck had an air filter sensor. The mechanics would not have had to move hoses around causing a check engine light to come on.

Why I Don’t Like Code Schools

Now that I’ve gotten you to click the link, let me be a bit more explicit: Why I don’t think code schools in the midwest are helping their students in their current iteration.  But see, that’s not as exciting and nobody is going to think “I have to read that.”


Let me set the stage by being clear. I know of 3 code schools, and so this is based on my interaction with them.  What I’ve noticed, though, is that all 3 have something in common. First, their language of choice: Ruby.

I understand this choice. It’s a nice, dynamic language, that has a tendency to read like an English statement, or at least more so than C-style languages. The fact that it’s dynamic means it has some advantages, like being easier to test. Additionally, there is a lot of literature about how easily testable Ruby apps are (in practice, I understand, they’re don’t often take advantages of that feature.)

In addition to the nice features of the language, it has the advantage that other code schools are using Ruby for their curriculum. What that means is, there are curriculums out there that can be followed. Others have developed and iterated their curriculum, so if you were to start a code school today, you could theoretically borrow from one of those.

However, Ruby is also a problem for the code schools that I know of.  As I said, I know of 3 schools, these 3 schools are in 2 separate towns in the Midwest (Omaha and Indianapolis.)  I am way more familiar with Omaha than Indy, but I spent a bit of time talking to people in Indy recently, and what I found was what I’ve seen in Omaha. Ruby is not a popular language in either town. In Omaha, I know of two places that do a fair amount of Ruby development. Neither are “big” shops, which means they don’t have dozens of openings.  The “big” places in Omaha are predictably using .Net and Java.


I can almost hear you saying “They just use Ruby to teach, but the students can get a job in any language.”  Which is a noble goal. It sounds like something a 4 year university would say. When I graduated back before the dot-com bubble, my school offered 2 languages that I know of, Fortran and C++. From talking to students now I know that they use Java a lot more now than when I went through. But the point, at least in my school, was to learn how to program. That is, understand pointers, and data structures, and numeric approximations, etc.  That is, concepts in computer science.  Turns out once I decided to turn away from hardware and focus on software, I actually did use C++, but it looked basically nothing like what I learned in school. For example, I never heard of STL in undergrad, but used it extensively on my job. I’ve also never taken a class in .Net or JavaScript and have used both as my primary developing language over the years.

So why can I apply that lens to myself, but not to the code-school students?  It comes down to this, my school did not ever promise me that I would land a job programming in C++. To be fair, I was getting a degree in Electrical Engineering, not Computer Science, but even so, they didn’t tell the CompSci kids that either.  But that’s what code schools promise, essentially, “Come do our course for 12 weeks and we’ll help you land a job.” That’s a lot to promise in 12 weeks.

One of my hobbies, as I’ve discussed here in the past, is Brazilian Jiu Jitsu (check out my CouchJitsu blog if you’re interested.)  In that martial art, you start by learning specific techniques.  For example, “How to do an arm-bar from closed guard”, then “How to do an arm-bar from mount”, then “How to do an arm-bar from open guard” etc.  However, there is a saying in that sport that I’ve heard “techniques, then concepts.” What it means is, you start with techniques, because you don’t know anything. So you learn the five steps to arm-bar from closed guard. Over time, however, you realize there is a concept of an arm-bar, and once you learn that, you stop focusing on steps and techniques, and instead focus on the concept of hyper-extending an elbow.

The same thing is true with programming. You can teach someone how to retrieve a database entry using ActiveRecord. Then you can learn how to do the same thing using NHibernate or PetaPoco or some other ORM.  Eventually, you understand the concept of ORMs and data access. Once you understand that, you can start more easily pick up different ORMs. For example, I’ve used no less than 8 ORMs in the past 8 years, because I understand the concept of ORMs.

I have not seen this practice with graduates from Code School. The graduates I’ve talked to understand ActiveRecord, and how to use it, and in some cases, how to test it. That’s to be expected, because that’s the dominant package in Rails, and it’s what they’ve been taught in their code school.


This last area, I first considered calling “promises” but I’m not sure any of the code schools actually make promises. So I changed it to assurances. That is, the school assures their students that they’ll be more marketable after taking this course.

For the most part that is true. A lot of people are doing reboots, they’ve left career paths where they’re at a dead end. Which means that they’d gone as far as they could go. By starting to get into development, they’re giving themselves a much higher ceiling and that’s great.

But as I’ve mentioned, based on the language of choice, as well as how they’re taught (given their time constraints) they don’t have a lot of options, at least not in the two towns I’m aware of.  First, it is unlikely, at least in Omaha, that they’ll go to a software company writing Ruby. Not impossible, mind you, just not likely.  Additionally, because of the limited amount of time they’ve spent developing software (even at 50 hours a week for 12 weeks, it’s still just 600 hours of total development) they’ll often find themselves in Junior level, at best. That’s not 100% their fault either, but most employers will look at the things they have to still teach these graduates and be unable to bring them on much higher than junior level.  And to be honest, our industry as a whole fails in hiring people with little experience (even those that gradated from a 4 year degree.)


So that’s a lot of complaining. What kind of solution can we come up with?  For starters, what if we chose a different language?  JavaScript is largely becoming ubiquitous. Further, it’s not just the client. A school could teach NodeJS for the server side, and still teach either vanilla JS or even pick a framework (Ember, React, Angular, Backbone, etc) and teach that on the client. That alone would make them more marketable, because even if they were unable to find a backend job, having JavaScript as a skill would open up a lot of doors for them.

The other thing that I could help is to work with more companies in the communities that the schools are in.  I know in Omaha there are companies that help out and mentor, but perhaps a different approach would be to land someone an “internship” at a company and then have them sent to the code school.

Overall, each student I’ve talked to, I walked away feeling as if they had the impression that they would take this course and find a job writing code pretty quickly. And from what I’ve been able to tell, that’s not happening.

My Weekend in Indy

This weekend I had the opportunity to speak at Dev Workshop in Indy. It was only the second time I spent any time in Indy. The first was when I came to the Chiefs playoff game in 2006. Since it was the Chiefs and the Colts, it didn’t go in my favor (but at least it wasn’t that Chiefs/Colts game.)

I heard about the conference on a mailing list I’m on, and I thought “I’ve been wanting to expand the area I’ve done conferences in” so I emailed back and submitted some talks. I usually submit 3 or 4 talks in the hopes that 1 or 2 will be picked up, so I was quite shocked when I heard that they wanted me to give all three. I was there to speak, and speak I would.

I got in late Thursday night, in part because IL is under a constant state of construction and in part because I forgot IN is Eastern and didn’t plan on the time change. That was ok, I relaxed a little bit before I went to sleep so I could get over to the conference first thing in the morning.

One of the things that I noticed, and it made me quite happy, was the diversity of talks.  There was a 2-part series on EmberJS, a 2-part series on Android development and a 3 part on iOS development. All 3 were live coding.  After that there were 2 talks on resumes and one on finding your next job (mine).  There was an amazing talk by @funkatron on mental health in the tech world.  You should go check out his talks. Seriously. Every developer needs to watch this. And that was just day one.

I judge conferences in a couple ways.  One, the variety of topics they cover. Not every conference needs to be a polyglot conference, those are my preferences, but even monoglot conferences can be really good, provided they cover a variety of topics on that single language.  Dev Workshop had quite the variety.  Another way that I judge conferences is the hall way conversations.  I enjoy going to talks and listening to different topics, but I typically get more out of conversations going on outside of the talks than I do inside. Once again Dev Workshop had some good conversations going on.

One thing they did that I really liked, was instead of hitting the bars Friday night, they held a career fair. I hung out for a while. I’m not looking for a job, and I’m definitely not looking for one in Indianapolis (don’t read that the wrong way, I just love Omaha.) But it made sense. You have a lot of people who are passionate about software development (why else are they at a conference) you have recruiters and companies that need good developers. Where do you find good developers? At conferences.  It will be interesting to hear if people landed interviews or jobs out of there, but it was a good time to hang out with developers and talk.

Finally, the organizers were super nice.  They were bending over backwards to make sure that things were going smoothly and speakers were taken care of.

All in all, this conference, which is only in its second year, was 100% worth the 20 hour round trip I’m going to spend in the car.  It’s exciting to see its potential as well, and hopefully it continues to grow in the coming years.

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.