HDC 2016 Keynotes

I really enjoyed attending the 2016 version of the Heartland Developers Conference (HDC). I want to share some of the things that I took away from the conference this year.

The biggest highlights for me were the 2 keynotes on day 1 of the conference. Tarah Wheeler kicked off the show with a great talk that focused on mentoring. Jeremy Clark finished the day off with a complimentary talk about how to be more social and interact with fellow developers at events like HDC.

Tarah Wheeler's Keynote

From Tarah's speech I gained a lot of encouragement to go forward and work to help mentor others in the community. She has found that when she gives to others that it has opened doors for her in the future. Even just giving someone encouragement can build a relationship that benefits everyone involved. Mentoring doesn't require you to know everything and not even a lot more than the person you are mentoring. Knowing just 1 more thing than your mentee still provides them with knowledge.

Once you start giving, other will seek to help you. I believe the reason for this is tied to Tarah's advice on who to mentor. She said to look for others that are already giving themselves. If you are giving and your mentee is giving then you form a mutually beneficial relationship. If you seek out someone that is not interested in giving themselves, then you will likely be frustrated by the effort that person gives you back.

Tarah was a great speaker and had a great message. If you have the opportunity to hear her talk, I would highly recommend doing so.

Jeremy Clark's Keynote

Jeremy covered 2 main topic. First was User Driven Development. A few of the main points I took away from this keynote were:

  • His biggest successes were when he knew what the customer needed and his biggest failures where when he didn't.
  • My job, as a developer, is not writing code, it is solving problems. To achieve this, you need to understand the users and their needs not just what a spec tells you to do.
  • It is important to build trust with your users.
  • Care about making things better. If you want to make things better all the time, you will have a greater impact than just writing code.

He also had a couple of good quotes that can be used as a guiding principle for helping the user. "I fight for the user" and "I need to know the user because the user doesn't know the technology."

And he also had a good story about a place asking him to make the system do what it does today. His response was, "We are rewriting it because it is broken. What it does today is not working." Eventually he was able to come up with a simple solution to solve what the users needed rather than just having it do what it already did.

Then he focused on Becoming a Social Developer. When you are around a group of developers like at a conference, you know 2 things that you have in common with anyone there.

  1. You both love technology
  2. You both want to learn

So given this knowledge you can fairly safely assume that you and any other developer you are around can find something to have a conversation. You can take a fairly small risk by asking someone if you can join them and they will most likely say yes. Even if they do not, the worst thing that can happen is really not very bad at all.

This part of his talk really synergized well with Tarah's talk. By being more social, and being willing to start conversations, you will create new relationships. Those relationships might lead to opportunities in the future or they may just be a learning experience.

Many developers think that they are too shy to be social in this way. Jeremy said that shyness is a learned behavior and just like any behavior it can be changed. He gave some tips on how to overcome that behavior and challenged everyone to meet someone new at the conference. I was able to complete his challenge and met a few new people. Some of the conversations I had went better than others, but I was able to complete the challenge and should have an easier time of it in the future.


Double Back Development

Have you been stuck on a problem at the end of the day only to think about it all night? Then when you start work the next day, you are able to solve the problem quickly. I think I may found a reason that happens.

I got this idea from listening to this TED talk: Can Slowing Down Help You Be More Creative?

In this talk, Adam Grant discusses how procrastinating can lead to more original and creative ideas. He found that there is a curve for creative ideas. People that get things done as soon as possible and those that get things done at the last possible moment tend to produce the least creative work. However, someone that puts things off a little is allowed to let new ideas form and still has time to actually implement them.

One of my biggest takeaways was the idea of, “Quick to start, slow to finish”. To cultivate creativity, you want to start a project off as soon as possible, but then set it aside and leave it alone for a while.

With this in mind, I am suggesting a different approach to how we develop code. I call it Double back Development.

Double back Development is the idea that you start a feature, you get some of it done, but then you do not finish it. You move on to a different feature. You continue this pattern to get a few different threads going. Then you double back to that first feature you started a while ago. You get to continue work on this feature with fresh ideas. You also have not devoted so much time and effort into it that it feels bad to start over if your new approach requires. I think this will lead to more creative solutions.

Will this idea work? I don’t know yet, but I plan to experiment and find out.


Not or Bang versus Equals False

I generally write code in C#. There are 2 mains ways that I have seen to check if a Boolean expression returns in the negative.

Using a bang to symbolize "Not" before the expression


And checking if the expression equals false

(expression) == false

I have gone back and forth between using both never really having a strong feeling as to which I prefer.

Today I have decided that I believe one is better than the other.

I came to this conclusion by really thinking about the Principle of least surprise. The principle when applied to coding is that you want your code to not surprise the next developer. What can you do to make your code easy to follow and understand?

Viewing these 2 options under the lens of the Principle of least surprise, I think one is clearly more surprising than the other. I think that using the bang before an expression is much more surprising than equating the expression to false. The little exclamation point can get lost while reading code, especially complex code. 

Now I will use equals false going forward to make my code as unsurprising as I can.


Team Sharing

I work for a company that has multiple developments teams all working on different projects. Some teams work closer together towards a large goal, while others can be somewhat isolated. One team may work large on a web project while another is focused on mobile and another still could be just back-end services. There is collaboration between teams when it makes sense or one team depends on another, but I wonder if there aren't more opportunities to share knowledge and get teams to learn from each another.

My idea is to have 1 week where a developer from each team would join another team. The developer that changes teams would join their new team as if they were a new hire of that team. They would get great exposure to how that team works and would also get to work on something different than their normal project. With every team sharing a developer, each team would get fresh ideas and views of how they work. After the week was over, the returning developer would have new knowledge to share from the team that they worked with.

Working with a different team for a week could also create new lines of communication as 2 people that might not have otherwise had a chance to work together would now know more about each other. I believe team sharing would create more of a community between teams. I also think this could boost morale by changing things up a bit and having that feeling of newness.


Say Yes

I recently went on a team outing where we took an improv class. One of the ideas of the class was that you need to accept the idea provided by your partner(s) in the scene. If you contradict that idea then you are taking away from what they are trying to build for the audience. The core idea is to "say yes" and go with the flow of the scene. This will tend to lead to funnier moments than if you are are fighting against your partner(s).

This made me think about how life outside of improv and comedy is normally not this way. The instructions to the class to "say yes" are needed because this is not the way most people behave most of the time. How often do you hear someone disagree with a suggestion someone else gave them? It's almost like a reflex to some people. No matter what the suggestion is or who it came from they disagree with it immediately and clearly couldn't have considered the suggestion. I wonder if that sort of mindset leads to a negative outlook on life? By always being negative you only see the world through a negative lens. 

I think it would be better to try to be the opposite. Say yes. If you are given a suggestion, start out by accepting it as a good idea and that you should follow the suggestion. If you start in a positive place and you come to the conclusion that you should not follow the suggestion, then at least you reasoned out why it wouldn't work as opposed to dismissing it out of hand. You will have a solid reason for not following the suggestion and you will have thought through your options. You will likely be grateful for the suggestion and feel like it helped you understand your situation better, rather than thinking of it as a waste of time or a hopeless idea that would never work.

I also think it is a good idea to say yes when someone asks you for a favor. It is generally going to be easier to just say yes and do a quick favor for someone than saying no. Most people are not going to bother you with some overly complex and difficult task, they are going to ask for something simple and something they themselves would be willing to do for you in reverse. If your first reaction to, "Hey could you grab me that item over there?" is yes of course, then both of you are going to end up happy. The person asking gets their item and you never let negative thoughts enter your mind so you are happy to have helped. If instead, your first reaction is "I don't want to do that," chances are you are going to end up doing it anyways so that you don't look like a jerk. The other person is going to either be happy if you hide your annoyance well or feel bad that you are annoyed and probably not want to be around you as much. You are going to be annoyed and unhappy over something small and insignificant. 

I know that for myself I do not enjoy being around people that are always negative. I do not like talking with people that immediately shoot down my ideas without thinking them through. I want to be happy and positive and if someone does not help me achieve that, I would rather spend time with someone else than them. I believe that keeping yourself in a positive mindset will lead to a happier life. If you do not fight against things and go with the flow, people will be more interested in being around you. You will likely have better and more experiences as well because people will invite you to do things with them rather than avoid you whenever possible.

Say Yes. Stay Positive. Be Happy!


Take a step back and understand what your code is doing (Refactor)

I was recently fixing a bug in some code and while I was figuring out what the problem was I came across some code that looked something like this:

If x == 1 Then

No matter which path the code took the result would be the same as just calling doWorkBasedOn and passing x as the parameter.

My assumption is that someone started this code doing the check for x and then calling doWorkBasedOn(x) assuming that future logic would not always result in the same path. Then someone else, I hope, came in and added the else statement to get their story completed without really looking at what the previous code was doing.

Regardless of how the code got to this state, the last person to work on it should have taken a second to step back and look at what they were doing. Because this code was needlessly complex, a bug was introduced. Had this been done without this extra complexity it would have worked correctly the first time. If at any point someone had really looked at the intent of this code they probably would realized that it was doing more than it needed to.

I would suggest to take a step back and look at what your code is doing before and after you work on it and see if there is extra complexity that you can remove. This will keep your code base as easier to understand and less likely to contain bugs.


The role creativity plays in programming

I consider myself to be a very logical person. I tend to favor practicality to aesthetics. I feel like this lends itself well to being a developer. I think that logic is seen as a key trait when looking for a developer. I agree, a big part of being a good developer is about being able to think through a problem logically and come to a conclusion that will solve the problem.

I think that one thing that separates really good developers is that they have at least some amount of creativity. Logic allows them to see the problem and work through how to best solve it given their past experience and knowledge. Creativity allows them to see a problem differently and come to a solution by seeing how things can work in a way that they have not done before. Creativity allows for connecting ideas not previously used together to creates something new.

If you want to improve yourself as a developer, I would suggest that you do something creative outside of work. Expand what you do and gain new experiences. If you can't think of anything that you do that is creative, start. Take a painting class. Go to a park and draw something. Try doing some acting or perhaps singing. Taking photographs can be a form of creativity. It requires you to view the world around you in a different way and figure out a way to capture it. There are many different ways you can express creativity. If you don't like one activity try something else until you find something that you do like.

I write this blog. It works a different part of my brain than what I do day-to-day. I get excited when I get an idea for a post. I have some vague idea of what I want to get across in the post and I get to go on a journey to discover how to express that idea in words.

Have fun exploring your creative side. If at first you do not feel like you are very good, but you are having fun you should keep doing it. The more you work on your creative activity of choice, the better you will get at it. So try out some creative activities and see what you enjoy.