2016/07/22

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 while reading code, especially complex code. 

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

2016/07/06

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.

2016/04/17

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!

2016/04/08

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 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.

2016/04/03

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.

2016/03/14

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 Friday." We would start of the day with the meeting and end the day with the Developer User Group. The rest of the day would be devoted to innovation. Developers would not focus on new features that are in process, but instead be able to focus on other things. This could be just refactoring a portion of a system that they see a need to clean up. This could also be spent with members from different teams in an effort to learn from what other teams do differently. It could be developers forming new groups to work on something together, for example and angular directive that would be used by everyone and provide consistency across teams. It could be used for dedicated training as well. Really anything that gives teams a little break from the norm and gives them an opportunity to focus on something different and hopefully solve some different problems.

This would be roughly 5% of an employees time which seems more likely to be approved by the business.

2016/01/21

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.AreEqual("Hello World", result);
}


So the person learning would need to write 3 lines of code to create the test, and it would teach them a ton about how pieces of code interact with each other. They wouldn't be exposed to complex concepts yet, just a simple linear set of commands. They would then run the test, which would of course fail because the Target doesn't exist yet.

Next is where the coding "hook" happens. You help them write the system under test, at this stage it should be a simple 1 line of execution and spit back out the input. They run the test again and it passes. For me at least, this would provide the same sort of thrill as seeing the "Hello World" example because I just completed my first task. This would introduce them into "game" of TDD where you start with a quest, a failing test, and complete that quest by making the test pass.

From here you can introduce more complex logic, you continue the process and the student learns how to write code using TDD first.