Jon Kruger -
  • About Me
  • Blog
  • Values
  • Presentations
About Me
Blog
Values
Presentations
  • About Me
  • Blog
  • Values
  • Presentations
Jon Kruger
Uncategorized

A matter of perspective

There are lots of difficult situations in life. However, it is up to you to decide how difficult they are going to be.

As of last Thursday I have a newborn living in my house. While this is awesome, it will probably be several months until I can sleep all the way through the night again and I’m often awake at 2:00 AM rocking a baby to (hopefully) sleep. There are more or less two ways that I can deal with this:

  • Stupid kid, why won’t he just go to sleep??!?!??
  • God has blessed me with this cute little addition to our family and I get the honor and privilege of teaching him how to sleep, eat, play, and live.

Regardless of which of those two viewpoints I take, the reality doesn’t change: he’s going to keep me up at night. There’s really nothing I can do to change that, that’s just how newborns are. But I can change the way I look at it and the attitude that I take towards the situation. As a result, I’m now smiling at 2:00 AM as I look at our little youngster instead of being bitter about having to roll out of bed yet again in the middle of the night.

The same idea can apply to any difficult situation in life, including your career. Maybe you’re stuck doing boring maintenance work, working with less than stimulating technologies, or just not doing what you’d really like to do. While this can certainly be draining, try and take a new approach to it: in the morning when you get to work, choose to strive to be the best that you can be with whatever technology you’re using. Try and find new ways to get better and faster at it. Turn those hindrances and constraints into a challenge. Don’t let the situation determine your happiness or your motivation.

Every day you have a choice to be awesome at what you do or to find ways to be negative and let things tear you down. It’s much more fun to be awesome!

October 18, 2010by Jon Kruger
Ruby

My life as a Rubyist: a 4-week checkpoint

I’m 4 weeks into my Ruby on Rails gig and so far I’m loving it. Ruby on Rails is an awesome platform for developing web applications and it allows you to do things really easily. The Ruby language itself is extremely flexible. It has far fewer restrictions compared to static-typed languages, which enables to do things that you would’ve never thought of doing before. (If you’re curious, watch these screencasts on the Ruby object model and metaprogrammming, it’s some real mind-bending stuff).

The app that I’m working on is 4 years old, yet the codebase is probably the cleanest brownfield app I’ve ever worked on. The team puts a lot of emphasis on writing clean code and doing things right. I’m excited to work in a place where this is valued so much.

I noticed really quickly that there were very few really long methods in the codebase. The more I thought about it, I realized that this is not just because the team is making a concerted effort to write small methods (although that is part of it). You can do a lot in Ruby with not a lot of code, so you don’t need to write as much code. This leads to smaller methods, more readable code, and less code that needs to be written.

TDD is much more valued in the Ruby community. At JRubyConf last weekend, when they asked how many people in the audience practiced TDD, at least half of the people raised their hands. Everyone on my team knows how to do TDD. JRubyConf had three sessions on advanced TDD topics. None of them felt the need to convince people why TDD is good.

There are many more reasons why I like the Ruby on Rails platform (much more on this later). When you can do things using less code, there are countless open source packages that you can take advantage of, and when all of the tools you need to run tests, deploy your app, and migrate your database are already taken care of, you’ve drastically reduced the cost of change and developing applications (and don’t just take my word for it).

I’m not leaving the .NET world forever, but the Ruby on Rails world is more aligned with how I feel software development should be done (particularly when it comes to Agile, TDD, and software craftmanship). This doesn’t mean that .NET is bad by any means. But when it comes to developing web applications, Ruby on Rails has been quite an enjoyable experience.

October 11, 2010by Jon Kruger
.NET

NuPack = win

If you’re a .NET developer, you probably heard that Microsoft announced NuPack this week. This will allow you to easily find open source projects and pull them directly into your project.

Here’s why I think this is really awesome — this is going to enable all kinds of open source development. Sure, it’ll be easy to pull in the big open source projects like NHibernate, but you already knew about NHibernate. I’m talking about the small, more specific open source projects that do more specific things like pagination of tables in web sites, OpenID authentication, manipulating Word documents, and such. There are lots of these sort of things in the Ruby world, and it makes development really easy because I can pull in all kinds of open source libraries from rubygems with one command from a command line.

Not only will it be easier for people to find open source, it makes developing open source cool. People out there will be trying to be the one who develops everyone’s favorite table pagination plugin for ASP.NET MVC, or a .NET wrapper for the jqGrid, and any number of other things.

I’m excited that Microsoft is putting their effort, developers, and money behind something like this and I hope that this will have a real and lasting effect on the .NET ecosystem.

October 8, 2010by Jon Kruger
Ruby

JRubyConf recap

When I started at my Ruby gig last month, my co-workers encouraged me to attend JRubyConf. I am really glad they did.

This conference was exactly what I’ve wanted from conferences in the past:

  • Primarily expert level talks on technologies that we already use (or new versions of technologies that we already use)
  • A good amount of inspirational or non-technical talks
  • Three talks in a row on testing! (and none of them were intro-level)
  • Most of the room raised their hand when someone asked how many people do TDD

The Ruby community is very willing to learn new and better ways to do things, and learning is encouraged and appreciated. This is very clear from the way this conference has been run, and it’s not being done in a condescending way. The bar for conferences that I attend has been raised quite a bit now.

Jim Holmes has been promoting JRubyConf (which has been known as eRubyCon in prior years) for awhile now, even for people who didn’t do Ruby. I would definitely second that, a .NET or Java person could learn a lot from seeing how things are done in Ruby (and the less technical talks apply to anyone). However, you may leave frustrated if you’re not currently able to use Ruby at your day job!

October 4, 2010by Jon Kruger
Speaking, TDD

I’m speaking on TDD tomorrow at Agile Lunchbox

I’m speaking on test-driven development at Agile Lunchbox Wednesday afternoon. The meeting is at the Quick Solutions office (440 Polaris Pkwy, Suite 500, Westerville) at 11:45pm and food is provided.

This will be a more business-focused version of the talk. There will be some code, but this is more about why we do TDD and behavior-driven development, the benefits of TDD, the theory behind it, etc. So bring your managers and PMs along too!

September 28, 2010by Jon Kruger
.NET, Ruby

I’m not going to be that guy

This week was my second week working on a Ruby on Rails project. Even though I am thoroughly enjoying Ruby on Rails (more on this later), I’m not going to use this as an excuse to blast .NET, the .NET community, and anyone else associated with .NET.

I really don’t see how posts like this one do any good at all. You may be tired of Microsoft’s stance on things, and you might be tired of working with people who don’t share your values, and that’s legitimate. You may want to work on a platform like Ruby on Rails that you feel is going to make you more successful. But that doesn’t mean that you should go out in a blaze of glory and tear down everyone and anyone associated with .NET.

If you don’t like .NET, you have two choices, you can change your platform (i.e. switch to something like Ruby) or change your platform (i.e. make the .NET world better). There are a lot of people doing the latter, and to slam the entire .NET culture does these people a big disservice. I am very thankful for these people because they are making the .NET platform much better, and I’ve reaped the benefits of this over the years.

This post was initially prompted by this tweet from Jeremy Miller:

I don’t think there’s anybody more self-righteous and condescending than a .Net turned Ruby developer.

Seeing that 27 people have retweeted that, that tells me that he’s not the only one who is hurt by all of the anti-.NET sentiment.

A lot of people in the .NET community don’t agree with how Microsoft does things and what they stand for, and I fall within that group. I would rather see Microsoft spend less time on things like Microsoft.Data and LightSwitch and spend more time promoting good developer practices (like TDD), helping to create some kind of .NET package management system (like Ruby’s gems), SQL migrations (like Ruby’s rake), and the like. If you want to blast Microsoft for stuff like this, be my guest. They’re a for profit company, so they can act like big boys and take the criticism. But please don’t aim that venom at all of the good people in the .NET community who are spending a lot of their free time to make the .NET platform better.

September 27, 2010by Jon Kruger
Agile

Thoughts on pair programming (and when it makes sense)

Pair programming is a development technique used in Agile software development techniques like XP. Lots of people I know are big fans of pair programming, and many teams have everyone pairing on pretty much all coding activities. I’m just wondering if this is really the best way to do things in all situations.

To be fair, I’ve never been on a project where we paired all the time. I’ve paired off and on for various things. So I can’t really present the argument from the side of someone who pairs on everything.

There are many obvious benefits to pair programming, as you could imagine.

  • Onboarding a new team member
  • Senior developers pairing with junior developers
  • Working together on something particularly challenging

I’m not debating the value in this kind of thing. I’m just questioning the value of doing it all the time on everything.

I’ve asked a lot of people who pair a lot why they find it to have so much value. I’ve heard various answers, some of which I’m not sure I agree with.

The hard part of programming is figuring out how to do something, not the actual typing part.

This may be somewhat true… but to what extent? For most features, I usually sit down at the beginning and think about how to design things at a high level (and often discuss it with others). This certainly is the hard part, but once we figure it out, then I have to plug through the work and get it done, and doing this design doesn’t usually take that long. At that point, I see less benefit in having someone else there watching me, especially when I’m doing mundane tasks like HTML layout, setting up test data, etc.

Pair programming is actually faster than doing tasks individually.

In order for this to be true, that means that at least 50% of my time spent doing a task individually is wasted time due to bugs, rework, getting stuck, time spent figuring things out, etc. I don’t doubt that two people working together end up with better quality code in less time. But how much better? And can you honestly say that two of you can do it in half of the time compared to one of you doing it individually? Maybe in some cases this is true, but I would think that more often this wouldn’t be the case.

There are diminishing returns to pair programming. What I mean by that is this: if you and I paired on the same project, over time we would both learn the system better, we would start doing things the same way, we would design code better, we would learn new tricks and techniques from each other, we would work better with our team, and we would become more disciplined about writing tests and not cutting corners. But as time goes on, we would also be getting better at doing these things individually. We would be able to design things better individually, we would learn to be disciplined to write tests, and we would get better and doing things right the first time.

What if we were already able to understand how to design things correctly, we were already disciplined to write tests and not cut corners, we already communicated well and were team players, and we were better at development in general? In that case, I feel like pair programming makes less sense because the value we’re getting with pairing over individual development would be less.

On every project there has to be some balance between speed and quality. On one end of the spectrum you have startups who have to ignore quality and things like automated tests to just throw something together that seems to work so that they don’t lose their funding. On the other end you have some mission-critical project like a nuclear power plant or a pacemaker that can’t afford to fail. Those mission-critical projects need higher quality, but that comes with a lot of extra cost. Somewhere is the middle are our projects.

Obviously quality is very important, and if you know me you know how much I am a fan of TDD. But TDD, pairing, and anything else needs to be justified in terms of cost (both short-term and long-term). Is what we’re doing worth the time that we’re going to spend on it? The code has to work, that’s not negotiable. But since we have a finite amount of time to finish a project, we can only sacrifice so much speed in order to make sure we have quality.

When it comes to pairing, there are a lot of factors that need to be considered, namely how difficult your project is, what the business problem is, who is on your team, how experienced they are, and so forth. I’m not saying that pairing is bad in all situations. I’ve seen it work very well on several different projects, and like I said earlier, there are places where it definitely fits.

Now I am a proponent of having all code agreed upon by more than one person. You could do this with code reviews, pair programming, or assigning features to two people (who will spend time agreeing on the design, but won’t necessarily sit at the same machine and do the work together). I just want to make sure that we don’t have to waste time due to rework. I also emphasize to people that if they get stuck on something to please please please ask someone for help instead of trying to be a hero and spending a whole day trying to figure something out just because they feel like they should be smart enough to solve it on their own.

Again, I’m not saying that all pairing is bad, or that if you’re pairing on everything on your project that you’re doing it wrong. My whole point in this is that I think we need to evaluate each situation and decide how we can best deliver a solution with a sufficient level of quality in the least amount of time possible. Maybe that involves pairing, but maybe not. But I think we have to at least ask that question.

September 21, 2010by Jon Kruger
Ruby

Next week I start life as a Rubyist

My current assignment is wrapping up this week and next week I will be joining a team doing Ruby on Rails development. I’m really excited about this for several reasons:

  • I want to see if Ruby on Rails really helps me get things done easier and faster, as I suspect it will.
  • I’m anxious to learn more about doing things the Ruby Way.
  • I know half of the team and I like them, so that has to count for something!

The project I’ll be working on is a large application that has been around since 2006, so it’ll be a good example of a mature RoR application. It will be interesting to see how dealing with a mature RoR application compares to dealing with a mature .NET application.

Don’t worry, I am not forsaking my .NET roots! I’m looking forward to my Ruby on Rails experience and I’ll most likely be blogging about life as a .NET developer in a Ruby world.

September 9, 2010by Jon Kruger
Uncategorized

Planning for success

We all want to succeed at something, whether it’s your career, a sport, being a good parent, or whatever else you’re working at. But do you have a plan for succeeding?

The fact of the matter is that if you just hope that you’re going to succeed without doing something to make sure that you actually do succeed, it’s unlikely that you will achieve your goals. Most people do not succeed accidentally, they do it through many small decisions and actions over the course of time that lead them to success.

First, think about your personal mission statement in life. What are your priorities, and what is most important to you? Consider everything — your family, God, friends, activities, work, etc. This way when you set goals for yourself, you can make sure that they line up with your priorities. For example, maybe your work goals involve spending 20 hours a week doing something and as a result you don’t have any time to spend with your kids. If your list of priorities says that your family is more important than work, maybe you need to think about the goals that you’re setting to make sure that it’s the right thing to do.

Once you write out your personal mission statement and your priorities, it’s time to think about your goals. Do you want to learn how to do mobile development? Be a better spouse? Get to know your kids better? Be able to run a half-marathon? Lose 20 pounds? Brainstorm and write down a bunch of ideas.

Now that you have your ideas, evaluate them all and figure out which ones are most important. Think of your life and career like a business. What adds the most value to your life at this point in time? You can have different goals for different areas of your life (e.g. your marriage, your kids, your career).

Once you have your goals, think about the steps that you need to take to get there. Write them down and share them with someone else so that they can help you stay on track.

Now you have to execute. When you have to make a decision about what to do with your time, remember your goals and priorities and make the decision based on that. You certainly don’t want to make decisions solely based on things like feelings, what others might think, or what others say you should do.

This is what I do to make sure that I’m making the most of my life and it’s really helped me keep my priorities straight and be a better husband, father, and software developer.

September 8, 2010by Jon Kruger
AutoHotKey, productivity

What’s in my AutoHotKey file

I was asked awhile back to blog about what is in my AutoHotKey script file. If you don’t know what AutoHotKey is, it allows you to remap keys on your keyboard or create macros that are associated with keystrokes or key combinations. So here’s what I got.

#SingleInstance

#SingleInstance says that if I load up my AutoHotKey script and there is already one loaded, then just use the new one without prompting. If you make changes to your script file, you can double click the file to reload it. This way you won’t get annoying prompts when you do so. This has to be the first line in your AHK file if you use it.

SetKeyDelay, -1

By default, AHK puts a slight delay between each keystroke in a macro. I have no idea why you would normally want this, so the above line removes that delay and it will execute the keystrokes as fast as possible.

CapsLock::
Send {End}
return

Remaps Caps Lock to End. The Caps Lock key is in such a prime location in the home row, and you don’t usually need to use it. So I remap it to End, which I use a lot when I want to go to the end of a line of code. This way, I don’t have to take my hands off the home row and stab at the End key (and often miss). This was my first AutoHotKey shortcut and it still my favorite.

+Capslock::Capslock

Shift-Caps Lock will now toggle Caps Lock. Because sometimes you actually do need Caps Lock.

#j::run explorer c:proj

Windows+J opens the folder where I keep all of my code. The “run” keyword allows you execute whatever you want.

!^Up::
Send {Up}{Up}{Up}{Up}{Up}
return

!^Down::
Send {Down}{Down}{Down}{Down}{Down}
return

!^Left::
Send {Left}{Left}{Left}{Left}{Left}
return

!^Right::
Send {Right}{Right}{Right}{Right}{Right}
return

When I hit Ctrl-Alt-arrow key, it will go 5 characters/lines in that direction. This really helps you move around faster in a code file. Ctrl-left arrow or Ctrl-right arrow will go to the beginning/end of the current word, which is nice, but sometimes you want to go to a spot in the middle of a long word, so the Ctrl-arrow doesn’t really help. This is another favorite of mine.

:*:ssf]::
SendEvent select * from `
return

When I type “ssf]”, it will change it to “select * from “. The tick at the end of the second line tells AHK that the space at the end of the line is important and should be included.

:*:ietable]::
SendEvent if exists (select 1 from sysobjects where name = 'TableName' and xtype = 'U'){Enter} drop table [dbo].[TableName]{Enter}{Backspace}go
return

:*:ieview]::
SendEvent if exists (select 1 from sysobjects where name = 'ViewName' and xtype = 'V'){Enter} drop view [dbo].[ViewName]{Enter}{Backspace}go
return

:*:ietrigger]::
SendEvent if exists (select 1 from sysobjects where name = 'TriggerName' and xtype = 'TR'){Enter} drop trigger dbo.TriggerName{Enter}{Backspace}go
return

:*:ieproc]::
SendEvent if exists (select 1 from sysobjects where name = 'ProcName' and xtype = 'P'){Enter} drop procedure [dbo].[ProcName]{Enter}{Backspace}go
return

:*:newproc]::
SendEvent if exists (select 1 from sysobjects where name = 'ProcName' and xtype = 'P'){Enter} drop procedure [dbo].[ProcName]{Enter}{Backspace}go{Enter}{Enter}create procedure dbo.ProcName{Enter}({Enter}{Enter}){Enter}as{Enter}begin{Enter}{Enter}end{Enter}go{Enter}{Enter}grant execute on dbo.ProcName to EdwardsSteelUser{Enter}go
return

Prints out the following code when I enter “ietable]”:

if exists (select 1 from sysobjects where name = ‘TableName’ and xtype = ‘U’)
drop table [dbo].[TableName]
go

I put this at the top of the file every time I create a new database table. Also included are similar macros for views, triggers, functions, and stored procedures.

:*:se]::
SendEvent ShouldEqual(
return

When I write tests, I’m often writing things like “employee.Name.ShouldEqual(“Jon”);”. When I’m typing this stuff, I can just type “se]” and get “ShouldEqual(“. Sure, Intellisense could do it for me, but AHK is a lot faster than waiting for Intellisense to figure out what I’m doing.

:*:c:|::
SendEvent c:
return

Because I often screw up when typing “c:” and type “c:|” instead. You can do similar things for common misspellings that you often find yourself typing.

I have some other project-specific macros in my AHK file too. If you find yourself typing the same class name, database table name, or anything else over and over, create a macro for it. It’s a small thing but it will help you go a lot faster.

I wanted a way to add stuff to my file quickly because I knew that I would be more likely to do it if it were easier. This led to the AutoHotKeyShortcutAppender, which is a small console app that takes in two arguments: the key combination for a macro and the output. Now I can hit Windows-Q to bring up SlickRun and type “asc scn] SomeClassName” and instantly it adds the macro to the end of my AHK file and reloads it. (If you use the code, you have to edit the app.config file and set the path to your AHK file.)

Have any other AHK favorites? Please post a comment and let me know!

September 7, 2010by Jon Kruger
Page 14 of 24« First...10«13141516»20...Last »

About Me

I am a technical leader and software developer in Columbus, OH. Find out more here...

I am a technical leader and software developer in Columbus, OH, currently working as a Senior Engineering Manager at Upstart. Find out more here...