GenXJamerican

Steve Smith wrote this post regarding the problem with null about two years ago.  It’s definitely worth reading in full (as is pretty much anything Steve Smith writes).  The post provided code for the implementation of an extension method and a change in the main code that would address null without throwing an exception.  It also mentioned the null object design pattern but didn’t provide a code example.

I took the code from the original post and revised it to use the null object design pattern.  Unlike the original example, my version of the Employee class overrides ToString() instead of using an extension method.  There are almost certainly any number of other tweaks which could be made to the code which I may make later.

Smith’s post links additional material that’s also worth checking out:

• Tell Don't Ask
• Non-Nullable Types vs C#

Hanselminutes #427  was an excellent interview with Jonathan Barronville, the author (perhaps the most intelligent and articulate 19-year-old I've ever heard) of this article on Medium.  The discussion covered a lot of ground, and posed a number of thought-provoking questions.  Three of the questions struck me as especially important.

What is senior?

In the podcast, Hanselman suggested three criteria: years in industry, years writing code in a language, and age.  Since I’ve been in the industry for 18 years, have been writing production C# code for about 10 of them, and turned 40 at the beginning of the year, those criteria argue in favor of me being considered senior.  Those numbers can also work against me in a way (and not just because of the field’s well-known problems with age discrimination).  Before I took my current job (over 2 years ago), I hadn’t written any production ASP.NET MVC, jQuery or knockout.js.  The last time I’d written any production JavaScript before then was before also jQuery and node.js even existed.  So from the perspective of those technologies, I was junior (and still am in some respects).

While industry today seems to have a fetish for young developers, there is merit to that interest in one respect.  Men and women entering the industry right now, whether they’re fresh out of college (or even younger) are too young to have any memory of a world where Google didn’t exist.  They’re too young to remember a world before web pages.  Some of them have been writing software for the majority of their lives.  It’s natural to them in a way it wasn’t for me because I had to go to college to get access to really good computers and high-speed Internet.

That said, the number of years (or lack of them) isn’t an advantage or disadvantage if you haven’t had the sort of experiences you can grow from as a developer (and learned the right lessons from them).  Regardless of what age you were when you had the experiences, if you’ve had to build software that solved enterprise-level problems, dealt with scaling, refactoring and enhancement of large systems, or integration of systems, both succeeding and failing at addressing those challenges are what really make a senior developer.  More time in industry may give someone more opportunities to have those experiences, but if they haven’t had them, they’ve just been writing software for a long time.

What is the rush to be senior?

Hanselman made a comparison between tradesmen like carpenters and plumbers (who have to work as apprentices for 3-5 years and pass an exam before they can become journeymen) and our industry, where someone can have senior in their title without much experience.  While some of it (if not most of it) has to do with pay, there are drawbacks.  Because our field is relatively young in the grand scheme of things, there aren’t universally accepted standards and practices (especially compared to some branches of engineering, which have hundreds of years of history).  We place too much of a premium on speed, and not enough on depth of experience (and the time it takes to earn it).  One of the end results of this is the sort of interviews I’ve experienced on a regular basis.  I’ve seen tons of resumes from people with senior titles who are stymied by interview exercises that ask fairly basic questions (on the level of the Fizz Buzz test).

I’d been working for less than four years when I first got “senior” added to my title.  It came with a nice raise (which I was certainly happy about) and more responsibilities (team leadership), but I certainly wasn’t senior in terms of software development experience after that short a period of time.  Not unlike what the classic Peter Norvig essay suggests about teaching yourself programming in ten years, that’s about how long it took for me to see myself as legitimately senior from an experience perspective.  Even now, having spent over 17 years in industry, I’m sure there are workplaces where I wouldn’t be considered senior because I haven’t architected super-large systems or led a team with dozens of people—and I’m alright with that.  I’ve matured enough after this amount of time to be more concerned with what kind of work I’m doing (and what I’m learning) than I am with what title an employer gives me.

Are we okay with not knowing something and then learning?

This question points in two directions:

• are we okay with ourselves not knowing something and then having to learn it?
• are we okay with others not knowing something and then having to learn it?

For me, the answer to the first question is yes.  In the case jQuery and knockout.js (and other unfamiliar technologies like RavenDB), I had to be okay with not knowing.  Doing my own research, and not being too proud to ask a lot of questions younger developers on the team who clearly had more experience with those technologies was necessary to advance to the point where I could do all that work myself.

The answer to the second question is the key to many of the problems with our industry, particularly when it comes to issues of gender and diversity.  Too many in our industry go beyond not being okay with someone not knowing something and cross the line to being condescending, rude, and even hostile.  I’ve been on the receiving end of that kind of treatment more often than I care to remember.  Too many workplaces allow people with superior technical skills to act like children instead of adults in interacting with their co-workers.  There is more and more being written about the sexism in the industry (pieces like this one, and this one), but not nearly enough on the negative impact that environment has on the ability and desires of others to learn and grow as professionals.  I think the persistently low numbers of minorities and women in the tech industry has as much to do with the perception (if not reality) that a lot of tech companies have high “a**hole thresholds” as it does with insufficient exposure to math and science in school.

The bottom line for me from the article and the podcast is not only that everyone in this industry starts out as junior level, but that technology changes so quickly that we will all be junior at something at multiple points throughout our careers in the tech industry.  We need to keep that knowledge in mind so that we can be more patient with ourselves as we learn and with those we work with as they learn.

Important advice from The Pragmatic Programmer (page 62):

"Learn at least one new language every year."

Since Apple introduced yet another language (Swift) at WWDC earlier this week, I’m starting to learn that language as well.  So far, the syntax is a lot easier to grasp than Objective-C.  The only real hassle with writing the code examples as I read the language guide is that XCode 6 Beta crashes every half hour.

With both languages (or any language really), the real leap forward comes from building something non-trivial with them. Figuring out what that non-trivial something will be is another challenge altogether. I wish there were a sites like codewars.com (or Project Euler) that put out larger-scale problems intended to be solved with software. Being part of the developer interview loop at work pushed me to create a few problems of that sort for use in interviewing developer candidates, but none of those exercises require more than 20 minutes of work. More significant challenges should make it useful to explore features beyond basic control flow and data structures.

Last night, I gave a talk at Towson University to a section of software engineering students (a friend of mine is their professor).  The goal of the talk was to share advice and experiences that would help them in their careers.  What follows is the notes I spoke from, with revised and extended remarks (indicated by [extra]).

Overview

Software engineering involves a lot of collaboration.  In my role, in order to develop a single feature or piece of functionality, there could be a handful of other people involved:

We’d all love to work on brand-new software, but most of us won’t get the chance.  It is highly likely that the first work you do will be maintenance of and/or enhancements to an existing system.  So developing an ability to find bugs in software (whether you originally wrote it or not) will be important to your success as a software engineer.

Beyond Work

Keep in touch, keep learning, keep your skills sharp (and add new ones).  That’s a basic summary of the steps you need to take to go further in your career as a software engineer.

It is impossible to overestimate the importance of networking to your career (and I don’t just mean having a huge number of Facebook friends, Twitter followers, or LinkedIn connections).  By networking I mean staying in regular touch with people you’ve worked with in the past or know from school that you’ve enjoyed working with (and would like to work with again).  If you’re in the same geographical area, catch up with them in person once a year if you can manage it.  If you don’t live in the same area, go beyond a word or two on Facebook.  Don’t be the guy or girl who only checks in when they need something.

Having a strong one will not only bring you a wealth of useful advice and support when you need it, it will help you find work too.  A couple of examples from my own experience: a. I worked with a guy named Dave at USWeb.  We worked together for a couple years before I left and the company folded.  We kept in touch off and on over the years, but hadn’t had regular contact in awhile.  Over 12 years after we actually worked together, he gets in touch because he’s looking for a job and trying to decide between two companies—the one where I currently work, and one I worked for previously.  I tell him my current company is better (not just trying to be a good company man, my former employer was terribly dysfunctional) and write up a referral for him.  He gets hired and over a year later he’s still having a great time. b. Two other guys I worked with at USWeb—Murali and Allen.  One was director of technology, the other a senior developer.  I kept in fairly regular touch with Allen.  So after almost four years at Ciena, I’m looking for a change.  Murali, our former boss, is program manager at a local consulting firm and wants to surround himself with good people from previous gigs.  He contacts Allen first, but Allen likes where he is and isn’t looking to make a change.  But Allen gives Murali my contact information.  I interview, I get hired, I work there a couple of years before moving on to a management role at a different company.

Don’t pass up opportunities to expand your networks beyond classmates and people you’ve worked with in the past.  This area has plenty of software user groups.  They’ll have stand-alone website or be on meet up.com.  Join one.  Get to know people that regularly attend.  One of my current co-workers is someone I first met at a .NET user group in Rockville (RockNUG).  A year-and-a-half later, when he got tired of commuting from Maryland to Virginia to work, we talked after a user group meeting about openings at my company.  He’s been there six months now and is doing great work for us.

Figure out how you learn best.  Some of us learn best through reading.  Some through lecture.  Some through examples.  Figure out which one of these you are and spend regular time outside of work learning however works best for you.

Conferences and user groups provide great opportunities to network and learn.  Smart companies use them to raise their profile and to recruit new talent.  The companies I consider the best ones in my career are the ones that sent at least some of their employees to a conference or training every year.  Even when I haven’t worked for companies that pay for employees to get training, I believe it’s important enough that I’ve paid my own way on more than one occasion for a particular conference.  I went to SXSW Interactive last year and met up with former co-workers I hadn’t seen in 10 years.  I met people from all over the world, as well as a few people who were literally across the parking lot from me.  Seriously!  I met a couple of programmers and a designer who work at a small firm in a building less than 100 yards away, but we had to fly over 1500 miles to meet.

Blogs, podcasts and screen-casts provide great learning opportunities as well.  However you commute between home, school and work, it’s time you could spend listening to one of the many podcasts available on technologies or software development.

Starting a blog is a great way to practice and improve your written communication.  I first started back in 2003, and my only purpose was to have a way to remember the process I went through to solve particular problems that I could access from wherever I wanted.  On occasion, I would get a comment or two from others on the web that helped me solve a problem I’d posted about or improved on a solution I’d come up with.  Sometimes a post has been useful to other developers than myself.  I’ve even gotten requests for help in the comments.  Once you have a blog, it also makes a handy place to publish a linkable copy of your resume.  That’s a piece of advice your professor gave me many years ago, and now   I have plenty of visibility to companies (and recruiters) without really having to bother with job boards.

Giving a talk is a great way to practice and improve your verbal communication.  User groups are always looking for people to come and speak, and if there’s a technology that you know well (or want to know well), having to give a talk about it in front of an audience is one way to give yourself an incentive to research it and learn it well enough to be able to answer questions about it.  I try to give a few talks every year to one of the user groups I attend in Rockville.

[extra] Starting a podcast is another option you might consider.  I listen regularly to a few podcasts by veteran software developers (Hanselminutes, .NET Rocks, etc) and learn a lot that way.  But I think we would also benefit from hearing software engineers who are relatively new to the work world, or even from interns.  In addition to creating opportunities to hone both your writing and speaking skills, you’ll get to learn about audio and production.

With the amount of time you’ll spend working (and otherwise living your life), one of the habits that I’ve personally found the most difficult to maintain is writing code regularly that isn’t specifically for my job.  One of the benefits of school, especially in a computer science program, is courses where you have to learn multiple programming languages and produce working solutions in a relatively short period of time.  The diversity of languages is a great way to force yourself to think differently about how to solve a particular problem.  To the extent you make it a habit to learn a different programming language every year or two, the better your skills in your main programming language will become.

Music, martial arts, sports and medicine are endeavors that have practice built into them.  Software engineering doesn’t.  We usually treat our work as our practice.  You will improve more quickly as a developer if you practice designing and building software separately from the work you do everyday.

Practice!  There are plenty of sites out there with different code katas (small problems that you write code to solve).  Larger, longer-term side projects are also a great idea—especially if they’re tied to a hobby or something else that interests you outside of your job.  In addition to these, the web is full of open source projects that could use contributors (github, codeplex, sourceforge, etc).  Try to contribute however you can—even if it’s documentation—and you’ll benefit from the experience.

[extra] When it comes to practice in improving your software engineering skills, it works best if you consistently increase the level of difficulty.  John Sonmez explains why here.  He also links to an incredible example by Jennifer Dewalt.  Programming contests (including things like TopCoder) may be worth your consideration.

Yesterday, Bill Wagner (author of a number of excellent books on C#) wrote a post on string concatenation, string.Format, and StringBuilder.  I found it a useful update to what I previously understood.  I’d written a brief post on string.Format 7 (!) years ago, and at that time I thought string.Concat (a.k.a. “blah blah blah” + “blah blah blah”) shouldn’t ever be used because of the immutability of strings meant a new string was created for each concatenation operation.  Wagner touches on what operations create objects that will need to be garbage collected, as well as providing an example of when string.Concat is actually ok.

(h/t The Morning Brew)