Skip to main content


Showing posts from 2016

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 know

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

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 ! ( 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 wh

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 knowledg

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 outl

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      doWorkBasedOn(x) Else      doWorkBasedOn(x) 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

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 ex

Innovation Friday

Google famously had the concept that their employees could use 20% of their time to work on anything they wanted. This was meant to give their developers time to experiment and try out new ideas that they wouldn't have otherwise had time for. Sometimes these ideas turned into products and most of the time it didn't, but I bet their employees were always learning something that made them better and benefited the company as a whole. Most companies are probably not likely to want to "give up" 20% of their employees' time in this same way. My company generally has an all developer meeting on the 1st Friday of the Month. We get caught up with different projects and a look into what is coming up. We also have a Developer User Group where we will internally have a speaker from one of our teams showcase something they have been working on or something new they learned about. My thought is to combine all of those ideas into what I call "Innovation Frida

What if we taught Testing First?

I was thinking about how people are taught to program. It seems to me that most of the time, people are taught by quickly creating something. Its a "Hello World" app, or a quick Web page to display something. The idea is that you get to create something quick and easy and experience the thrill that comes along with that. From there you start digging into more complex concepts and with experience you learn how to do everything. What if we changed that to writing a test first? What if we used the TDD process of red -> green -> refactor to teach? The code required to write a test would be very simple. A single line for setup, the assembly step of a test. A single line for the system to do work, the act step of the test. Then a single line to prove the work did what was expected, the assert step. [Test] function GivenInputOfHelloWorld_Always_ReturnOutputOfHelloWorld(){     var input = "Hello World";        var result = Target.Process(input);        Assert.Ar