The Gilded Rose Kata for Swift

If you have never worked through the Gilded Rose kata, you’ve been missing out; it is canon when it comes to coding katas. It is unusual because it provides an initial implementation. Your mission, if you choose to accept it, is to add functionality to this legacy code. By the way, it is a huge mess! In order to make the work manageable, you’ll first have to refactor the existing code.

I wasn’t able to find the initial code in Swift, so I took a couple of minutes to port it. I used the code provided by Emily Bache as a starting point. You should definitely check out her repository if you want to try the kata in different languages.



Overclocking Your Brain

“How are you able to work on coding chops after a full day of programming at work? I am mentally exhausted by the time I get home and just can’t get motivated to tackle something new.” …, or something like that, is what I’ve heard from several people recently.

My answer: drugs.

Well, not exactly. I’m certainly not doing anything illegal. But, I have found some legal “nutritional supplements” that help me shake off the mental fatigue that I frequently encounter after coding my brains out at work.


Before I go any further, I feel obligated to remind you that there are no magic bullets. There is no substitution for genuine curiosity and tenacity. But, there may be things that give you a little nudge every now and then…

Enter nootropics. For the past few months, I’ve experimented with different combinations and dosages of nootropics with noticeable effect. I go to work, write the best code I know how to write, come home, spend some quality time with my family, then get back to writing code and mastering my craft. On those nights that I can’t shake the mental fog with a cup of green tea, I’ll put a little Noopept under my tongue and off I go. No kidding, it is almost like starting the day over sometimes. If I wake up feeling mentally sluggish, I might mix some Oxiracetam and CDP Choline in a glass of water. And there are lots and lots of different products available.

Again, taking supplements and sitting in front of the TV isn’t going to help you. Drinking protein shakes and sitting on your butt won’t make you muscular, either. But, if you’re pushing the limits of your mental endurance, it might be worth your time to do some investigation–there is plenty of research data available for different nootropics.

One more thing. I’m not a doctor, or in any way qualified to give medical advice. If you decide to experiment with nootropics, you need to do your own research. It might also be wise to consult with a doctor to make sure there aren’t known interactions with any other medications you are taking.


Anything you can code, I can code better (The IKEA Effect)

I am fascinated by cognitive biases. I hope you’ll find them interesting, too, because I plan to discuss several of them on this blog as they pertain to software development. The first one I would like to write about is a blind spot that a lot of us have when it comes to code we wrote.

The IKEA Effect boils down to us putting higher value on something that we created or helped create. I have a lot of pride in my work and I’m not suggesting that pride is a bad thing. However, it can become a hinderance to learning and growth when we irrationally defend our creations.

Here are a few examples of things I’ve seen in my career:

  • Custom solutions for common tools like bug tracking software. This doesn’t make a whole lot of sense when there are solutions created by people who focus solely on this problem.
  • Bubble gum and baling wire used to force a tool to perform a task it wasn’t designed to accomplish because someone has experience with that tool. This is also referred to as the “golden hammer“.
  • Reluctance to try a different approach because a lot of effort was put into the current implementation. This is also referred to as “sunk cost” bias.
  • This is the way we’ve always done it… Ugh.

And, here are a few suggestions to help you steer clear of the IKEA effect:

  1. Don’t take an alternative presented by another person as an attack on your solution. I know communication isn’t every developer’s strong suit, but, as a developer, you should learn to see past that and realize everyone is working toward the same goal. Sometimes you will have the best answer and sometimes you won’t, but you’ll never know unless you’re able to consider ideas other than your own.
  2. Remember that our industry covers a breadth so large that none of us can be an expert at everything. Before you decide to roll your own, consider that there may be a solution created by a 3rd party that has invested a lot more time and energy than you are currently able to pour into solving a particular problem.
  3. Don’t be lazy. It is often easier to understand something we’ve created ourselves than to take time understanding how someone else solved the problem. Fight that urge to default to whatever it is you happen to know and use the opportunity to get a different perspective. Even if you stick with your solution, you may pick up a few tricks that will help you improve it.

In the end, your solution may be the best solution. The important thing is to be able to consider alternatives without bias and be happy to learn when someone presents a better solution. If you’re on a team where your ideas always win out, you may want to consider changing teams. Surrounding myself with people who can challenge me has been one of the greatest sources of growth and success in my career.


Failure as a Catalyst for Growth

Several years ago I was contacted by a recruiter from Google. I was really excited and incredibly humbled that I had even been noticed by a company with their reputation. So, I pulled out my Cormen book (Introduction to Algorithms) and started franticly working through random problems using an IDE. My preparation was not only incomplete, but it was also ill-conceived. My naivety and lack of adequate preparation got me about as far as you might expect: nowhere.

Until recently, I only told a few people about this experience. I was embarrassed. I had failed. The funny thing was that I felt like I was at the top of my game at my current job. I had solved some memory management problems that were plaguing our product. I had been the champion for introducing automated testing to our team’s products. My yearly reviews indicated that I was doing exceptionally well. So, where was the disconnect?

The company I was working for afforded me many interesting projects. I even got to work on some machine learning code. Unfortunately, I hadn’t spent a lot of time thinking about how I would explain that work to a non-coworker. Instead, I ended up responding frequently to questions about my resume with: “I don’t remember the details.”

Next was a coding problem. It wasn’t a very hard coding problem. However, there were a few things that I hadn’t rehearsed that made things difficult.

1) I had been practicing in an IDE with code completion and didn’t realize how much I had been relying on it. I had to write my code in a basic text editor, so I didn’t have all my fancy productivity tools like autocompletion.

2) I had not practiced talking about what I was doing as I was doing it. It turns out that this is something that isn’t hard to master with a little practice.

3) I didn’t work nearly enough problems when I was preparing.

As soon as I hung up the phone with the interviewer, I pulled up my IDE and spit out a working solution in 5 minutes. I was so angry with myself.

Of course, this isn’t the end of my story. It turns out that nothing in my career, to this day, has motivated me more than this single experience. I started buying and reading lots of software development and computer science books. I had missed out on so much! I wish I had found Clean Code, The Pragmatic Programmer, and Code Complete when I was in college. But, there is no point in dwelling on the past. I needed to have these gaps exposed in order to fill them.

In an interview years later, I was told by an interviewer, “You should be careful about putting big words like ‘Metaheuristic Optimization’ on your resume because someone might ask you about that.” I was able to confidently respond with, “I came prepared to talk about that in as much detail as you’d like.” I was disappointed when the interviewer’s response was, “No, no need for that.” However, I did get a job offer after that interview.

All this to say, don’t be discouraged by your failures. Seize them as an opportunity to improve. If you aren’t failing frequently, you probably aren’t growing, so make sure to challenge yourself on a regular basis.


Growth Mindset

One of the main themes of this blog is learning. A lot of people, including myself, were raised with the understanding that IQ is fixed and that you do the best with what you’ve got. I didn’t realize how limiting that belief was until I discovered that it wasn’t true! More and more research is showing that we are, in fact, able to increase our intelligence.

As it turns out, one of the most helpful things you can do when trying to increase your intelligence is to simply believe that you can. One thing that I’ve observed during my career–and, I am sure is documented by many other sources–is that the people who solve the most insurmountable problems are the ones who don’t know that they are impossible. It seems that the older I get, the harder it is to not quickly dismiss something before giving it a shot. I can’t stress the importance of overcoming this “sad path.” Just try it! You may be very surprised at the result.

Another key factor is learning to embrace failure as merely another mechanism for learning. By pruning the decision trees that represent things unknown to us, we gain a much deeper understanding of whatever it is we’re seeking. In other words, to better understand what is, it is helpful to understand what is not. All those failures start to work like gutter guards (you know, those things that we use to help children learn to bowl) to keep you on a path to success.

Embracing failure as a learning opportunity is a very important part of something called a growth mindset. I first encountered the growth mindset while taking a MOOC taught by Jo Boaler, a renowned professor at Stanford, on learning and teaching math. I highly recommend her course, How to Learn Math. In the course, she talks about some of Carol Dweck’s work, which ended up being a jumping-off point for me. Also, Khan Academy, one of my favorite resources, is also endorsing the growth mindset. Check out their short video about it here.

Do yourself a favor and do a little digging for yourself. Start with the video I linked above and then maybe see what you can find out about Carol Dweck and her research. Check out Jo Boaler’s blog. Get inspired!