Business of Software

Time to Leave Your Job?

The Future Awaits - from http://us.123rf.com/400wm/400/400/rjmiz/rjmiz0804/rjmiz080400085/2836581-business-slogans-on-a-road-sign-exit.jpg
An article was posted over at Mashable titled 8 Signs It’s Time to Leave Your Job. I can see their perpective on all of their points, but to me their 8th point was the main point.

You are no longer passionate about your work and dread going to the office each day.

That is my number one criteria for looking for new employment. Do I dread going into work? Am I excited about the kinds of things that I get to do at my job? Not every day is a mountaintop, but if you have a prolonged period of dreading work, then you should consider moving on. All of the other points roll into that one. They talk about politics and high profile work, etc. Different strokes for different folks and some people aren’t affected by the same things that affect others. It all comes down to whether or not you die a little inside when the alarm goes off in the morning.

Assuming that you’re getting paid basically what you can make elsewhere (give or take a few percent) and that your benefits are fine, the only other consideration in my mind is whether or not your skills are being allowed to grow, or whether they are stagnating.

For example, if you are a .Net developer and your workplace is still working on the .Net Framework 2.0 and you are only using Web Forms and you are on SQL Server 2000 with no chance of an upgrade, you should think about going even if you are happy. Your alternative is to get very involved in “new technologies” in your spare time so that you don’t become easily expendable.

The days of working somewhere for 40 years and retiring with a gold watch and a pension are basically extinct. If you allow a job to manage your career for you, you will find a time where it is 2013 and you are looking for work and you have been doing FoxPro 6 or Classic ASP for 15 years and now you can’t find a job that will pay you anywhere near what you need to support yourself and possibly a family.

So it is all summed up very simply as to whether or not you like going to work every day. If you love the place and it is feeding your career, then you already know that you shouldn’t be looking anywhere else.

If you love the place and it is strangling your career, consider whether or not you have the time or inclination to put in the work “off hours” in a very big way to gain the requisite experience in “new technologies” that you may or may not use professionally. If you don’t have that time or inclination, look to move on, even if you love your job.

If you don’t love waking up in the morning to go to work, get out. Life is too short for almost anything else to matter.

Rant

How Deep is the Rabbit Hole

Programming is Hard, Let's go Shopping. From http://memegenerator.net/instance/30286782Rob Conery tweeted about a blog post that “Kakubei” made back in May of 2012. You can read about it over here.

I find it interesting that the author starts off the post making a comparison between himself and his brother. That his brother’s academic success and his own academic failings (and subsequent self-taught programming skills) are at odds and that the industry would view one of them as a “real programmer” and the other one as not a “real programmer”.

As I often like to point out, every programmer is a self taught programmer. You may get the fundamentals at college and learn some things that can make you more efficient or a better designer of computer systems, but with the pace that technology is changing, you have to constantly learn to keep up.

That being said, Kakubei’s main complaint is that Rails is hard to learn. He compares the canonical “15 minute blog” demos to what it takes to do “real world” Rails development and he comes up with a big differential.

What I find funny is that he seems to have come from a PHP background. That means that he had to know the PHP language, possibly a PHP framework (like Cake), HTML, CSS, JS, probably MySql, etc. I say that to say this, he had to know a lot to work and he wasn’t coming to Rails from zero.

The author complains that to use Rails, you have to know Ruby and that you have to know MVC, Gems, RVM, Active Record, HomeBrew, HTML, CSS, JavaScript/jQuery, Rake, Capistrano, etc. My point is that he probably already knows HTML, JS, and CSS. If he owns a Mac, he has probably already encountered HomeBrew (it isn’t just for developers). If not, this was a fine time to learn.

I think this all boils down to something else, though. What does it take to be productive or at least “mildly useful” in a language/framework?

To me, I was able to follow a simple Rails tutorial and starting using Rails almost immediately. Know what I didn’t need? RVM. Just starting out, I just used one version of Ruby and Rails. As for Gems, in order to do my tutorial, I had to say “gem install rails”, so I already had an idea how it worked. After that, you can pretty much avoid using it if you don’t mind rewriting code that is already a “solved problem”.

What about HomeBrew? Don’t need it. Active Record? All you need to know to actually make stuff happen is in the “15 minute” video. Same with the MVC pattern. I didn’t know anything about making MVC websites and I was up and moving with minimal instruction from the video. Rake? Didn’t need anything special there, either, because I hadn’t created a very complicated system yet. Capistrano? I need an automated deployment on day one?

My point is that every rabbit hole is very deep. .Net? WebForms or ASP.Net MVC? HTML, CSS, JS/jQuery. Dependency Injection with AutoFac/AutoMapper/Ninject. ORMs like Entity Framework, NHibernate, etc. Don’t forget the language (C# or VB.Net or F# or whatever). How about Nuget for package management? Don’t forget source control, like TFS or Git. What about knowing testing like NUnit, xUnit, MSTest? Deploying with MSBuild and MSDeploy or one of the bajillion open source tools?

I could follow the same path to describe getting started in web development with Node.js or Python or whatever you could think of. It is silly to think that you can go from 0 to Amazing in 15 short minutes. That pattern doesn’t work.

What you have to know is how to learn. You have to know how to Just-In-Time the information so that you can be productive from the jump off. Yes, that means that you’ll always be learning, but if that concept doesn’t excite you, then you are probably in the wrong field.

I believe that that sort of complaining (“The development stack is too deep/rich”) shows a certain level of professional immaturity.

I realize that after Rob tweeted, Kakubei added an update after people started commenting, saying:

“I’ve been using Rails for more than a year and I still use it. In fact, I’m in the process or rewriting our main application’s API in Padrino with ActiveRecord, Thinking Sphinx and deploying to Heroku and it has been a primarily positive experience despite some teething issues. The admin for our database I’ve written in Rails 3.2 and there is a lot to like there. The idea was to write another post after this one titled “Why I love Rails” but I never got around to it. Even though this post is a rant, I still feel that way about Rails, so keep those comments coming, but don’t feel you have to convince me that Rails is good, I just take umbrage with some of its complexities and with the people who sell it as being simple and easy to learn. In the meantime, I’ll keep ranting.”

I understand his response and understand that he was probably frustrated when he wrote the post and he is not really apologizing for it. That leaves me to still consider my criticism valid that I believe that he faced the problem all wrong (or at least described a method that did just that).

To me, you learn the basics of the thing. You see what skills you have that you can already reuse (HTML, CSS, JS, SQL, whatever). Then, you pick up what you need, working with the “training wheels” that the frameworks or languages give you. Then, steadily over time you start to grow and move deeper in the tooling until one day you are someone that others look to for advice.

That’s the only way we’re going to make it in this crazy development world.

iPhone

Best Nine Dollars a Month You’ll Ever Spend

I’ve been getting more and more into iOS programming recently. It is something that I’ve been doing more and more as a hobby, as well as landing a few paying consulting roles creating native iOS applications. I’ve kind of been “marinating” in iOS for some time, but about a year ago I started really getting serious and attempting to have an actual goal with regards to Objective-C and iOS.

One good FREE resource is the Introduction to iPhone series on TekPub with Ben Schierman. It was done a few years ago, and Rob Conery has now given it to the community. It is a little out of date, but you can’t beat the price and it will help you learn a few things.

I have a TekPub subscription, so from there I moved on to Show Me Objective-C, another Ben Schierman TekPub series. I really liked the way that Ben explained things, so I started doing a little cyber-stalking digging about him and I discovered his site over at NSScreencast.

Ben has some free videos there, as well. I downloaded and watched them all and learned a TON. His video about AFNetworking alone was worth the time. I noticed that he had a subscription package initially, but didn’t check back into it until I had watched all of the free videos. I’m glad I did. He offers full access to his videos (new ones weekly) for only $9.00 a month.

This is a BARGAIN!

I feel like – thanks to Ben – that I am an honest-to-goodness-real-life iPhone Developer now. I’m not scared of Xcode, I’m not mystified by Objective-C, nothing. With the videos he has to date, you can spend a weekend and gain an insane amount of confidence on the platform. I highly recommend it.

Goals

750 Words

Recently, I started using a site called 750 words. Its name basically sums up what it is. Basically, you sign up for the site and you just type in daily writings. It does analysis of your words and tells you all kinds of stats about what you’ve written, how long it takes you to write, how many interruptions you typically have, etc. According to the site, 750 words is about 3 printed pages of work, so you are making good-sized chunks of writing each day. Each entry is private, so you don’t have to worry about grammar or spelling (though you’d obviously want that to be improving as you went). Another neat feature is that the creator has made it very easy to export your writings. You own it, you shouldn’t have to worry about being locked in. I definitely appreciate that aspect of the site.

I started 37 days ago and I’ve completed 37 days. I’m a bit of a compulsive person, so once I build up a habit like this, it actually stresses me out to break it. I’m probably the poster child that the site’s founder had in mind when he created the site. Each month, there are also “challenges” that you can participate in. You sign up and commit to write something every day for that month. I’m 13 for 13 in December so far (obviously since I’ve written every day for the last 37). The site even lets you define a reward and a penalty for completing or not completing the challenge. There is no way to enforce it, it is just for fun.

The site is such a simple concept (the best ones are), but I’ve found it really helpful to get into a writing habit. At first, I would just write about my day. I haven’t had a private “general purpose” blog in a while, so I did that. However, that only lasted about 4 or 5 days before I grew tired of it. 3 pages of good stuff doesn’t happen to me EVERY DAY! My original goal was that I’d be able to free write and take notes and use those notes as primers for blog posts. I changed that goal a few weeks ago.

During TekPub‘s Black Friday Sale, I signed up for my own personal annual TekPub Subscription. Two years ago, my employer bought me one, but I work for myself now and I needed to invest a little more in my education. What I started doing was “live blogging” the videos as I watched them. This served three purposes.

  1. Complete my Daily 750 Words
  2. Watch a New TekPub Video Every Day
  3. Create Lots of Very Useful Notes For Future Blog Posts

To date, I’ve watched the entire TekPub Speed Series with Sam Saffron, the Node Series, and all of the Jon Skeet Stack Overflow Question of the Day TekPub TV videos, “live blogging” them all. Along the day, I have paused to journal some incredible days that I’ve had or some interesting projects that I was working on, but I always fall back to the TekPub videos as a great source of content. The bonus is that I’ve learned a great deal so far.

Today’s blog post is a little meta. This post itself is today’s 750 Words. No need to write 1500 words today when a little reuse can do. I’m a programmer, after all, appropriate reuse is the goal.

Why might 750Words.com be appropriate for you? Maybe you don’t have a blog, technical or personal. Perhaps you don’t see the use of writing all of these daily words with no intention of anyone ever reading it. I think for someone like that, the site still has merit. First, one of many developers’ greatest weaknesses is communication. I’ve seen it over and again that clients aren’t happy with the level of communication (particularly written communication) from their developers. And we all know that the best way to build a muscle is to work that muscle, so daily writing will help.

Secondly, you may discover that you have a love of writing. Maybe your words won’t ever get beyond the 750Words.com vault, but maybe you’ll write and find that you enjoy it. If 750 words really is about 3 printed pages, in 3 months, you could have about 270 pages of material. Assuming you kept a consistent theme or themes, you are actually a good deal of the way to having written a book. You could export your posts, edit them into a more coherent theme, and publish them to the world on the Kindle store.

Since book writing is something that I’ve always wanted to do at least once, I’ve certainly considered that route, but for now I’m just trying to build blog posts. Maybe one day soon, I’ll build that into a book. I don’t know now if it would be fiction or non-fiction, technical or not, for now I’m just enjoying the writing process.

So, if you can see any value in daily writing at all, head on over to 750 words and create an account and start writing. At the risk of being a cliché, the journey of 1000 miles starts with a single step. Do 750 Words today, take the first step.

Uncategorized

Implicit and Explicit Operators

Explicit SemanticsI came across an interesting article the other day. It was about a “forgotten” C# feature, the implicit and explicit operators. You can see the original article here. I do remember reading something about these operators years ago, but I don’t think that I’ve seen these operators at use in the wild, though I can definitely think of a ton of times that we needed it.

If you don’t know yet, the explicit and implicit operators help with converting one object of one type into another object of another type. The best use case for this isn’t for converting simple types like ints into doubles, but for converting more complex objects. One common example would be if you are using something like nHibernate or Entity Framework that generates classes for all of your database tables. However, if you are using WCF/Web Services/Remoting/Whatever, you might have different classes that need to exist before transmission.

Let’s pretend that we have the following classes:

namespace DataClasses
{
    public class Person
    {
        public string FirstName { get; set; }
        public string LastName { get; set; }
        public int PersonId { get; set; }
    }
}

namespace ContractClasses
{
    public class Person
    {
        public string FirstName { get; set; }
        public string LastName { get; set; }
        public int PersonId { get; set; }
    }
}

Now, we can see that the classes have the same names and identical declarations. Again, this is very simplified, but it is a real problem. This is one of the types of things that the excellent tool AutoMapper is used for. AutoMapper does this for you automatically, of course, but if you only need this for a few instances, you may not want to take a dependency. If you just try this code, you will get the error “Cannot implicitly convert type ‘DataClasses.Person’ to ‘ContractClasses.Person'”.

DataClasses.Person dcPerson = new DataClasses.Person() {FirstName = "Pete", LastName = "OnSoftware", PersonId = 7};
ContractClasses.Person ccPerson = dcPerson;

However, if you add this code into the DataClasses.Person class (either directly or with a partial), the above code now compiles.

public static implicit operator ContractClasses.Person (DataClasses.Person p)
{
    return new ContractClasses.Person()
               {
                   FirstName = p.FirstName,
                   LastName = p.LastName,
                   PersonId = p.PersonId
               };
}

That does make the code compile, but we are losing some of what is happening there. That is why the explicit operator exists. It allows you to not do a “hidden” convert, but instead make an explicit cast. If we change the code to look like this our code breaks again:

public static explicit operator ContractClasses.Person (DataClasses.Person p)
{
    return new ContractClasses.Person()
               {
                   FirstName = p.FirstName,
                   LastName = p.LastName,
                   PersonId = p.PersonId
               };
}

However, if we change our original code to this, we are back in business and much more readable.

DataClasses.Person dcPerson = new DataClasses.Person() {FirstName = "Pete", LastName = "OnSoftware", PersonId = 7};
ContractClasses.Person ccPerson = (ContractClasses.Person)dcPerson;

This isn’t limited to converting “identical” classes. Jeffrey T. Fritz, the author of the article above that inspired this post converted from an order class to a receipt class, for instance. I definitely believe that using explicit and implicit can make your code much more readable than using utility/conversion classes or extension methods to accomplish the same thing.