Wow, I’ve been busy. And I just remembered I have a blog! Sorry for the incommunicado.
Back in January I gave some advice to Jack from Australia in the blog post: Career Advice for a 19-year Old Programmer.
It definitely struck a chord because a number of folks asked me about their own situation.
Zebu asked:
“What would you suggest to some one who is 30 with basic knowledge of c#, c++ ?”
Julio and Dave encouraged me to reply to Zebu since they felt they were in the same boat. In fact, Dave added:
” I third that for I am in the same boat, however I’m in my forties, and have been a Windows Sys Admin.”
In a nutshell, my basic advice is the same … develop skill by writing software as often as possible. Demonstrate skill by showing completed projects to prospective employers. Contribute to FOSS — even if it’s just documentation or feedback. Make connections in the industry by going to industry events and introducing yourself and generally being an interesting person.
The only difference in what I recommended to the 19 year old who presumably has loads of discretionary time to spend on any pursuit he likes (assuming he lives with his parents, has no commitments like a family, house payment, etc.) is that you’ll have to commit to nights and weekends to the learning process (unless you’re lucky enough that your current employer will allow you to try and build some small software project on company time … something your boss can’t get funding to purchase, or can’t get the developers to build because they’re committed to other projects.) I’ll have more to say about the power of “nights and weekends” in another blog post.
However, there’s an undertone in these questions related to the commentors’ ages. In fact, Edgar says …
“I think the advise Bob has given to the 19y old guy is great and very motivational !
Now my question is what will be your advice Bob for a guy who is almost 40 years old and want to start his career on software development ? I’m planning to go to college next year. Do you think I have any chance to succeed and get a job after finnishing my studies or this is only reserved for young people?
Will really appreciate your advice and perhaps will keep me motivated to persist and continue towards my goals!”
So, that is a great question … is there any room in the software development industry for a 30-40 year old software developer, particularly one that has gotten started later in life?
I suppose the prototypical software developer is a male in his early twenties with no social life. Perhaps this caricature fits certain types of developers; for example, my perception of the start-up scene is that it is predominated by JavaScript and Ruby On Rails developers in their early 20′s (but that’s purely my PERCEPTION and may not be reality at all) but this I do know … I’ve not found that to be true in the Microsoft development culture.
My observations are definitely anecdotal, but from my limited exposure to the .NET community, I would say that people in their 40s and 50s are well represented at .NET community events, at conferences, and in many development shops I’ve visited. In several sessions I attended at the first Build conference, I felt amongst the youngest guys in the room, and I was 41 at the time. I can’t speak for other platform / cultures / etc. but again, I just don’t see that as a problem in the .NET world. Maybe I’m fooling myself with what I’m about to say …
While I don’t believe the problem to be ageism per se, I do think it has something to do with one’s experience and the perception of how far along he or she should be in his or her career.
Thus, it’s a cognitive bias problem.
Let me briefly use an illustration of cognitive bias to make my point. You and I are in the mall and we want to grab a bite to eat. The sandwich shop charges $17 for their meatball sub! You say, “Hey, we can get the same meatball sub for $7 at the other end of the mall … it will take us 10 minutes to walk over there.” We agree, walk for 10 minutes, order and enjoy our lunch. Our next stop is the suit store — you need a new suit for an interview. You see one for $500. BUT I remember I saw the EXACT SAME SUIT for $490 back on the other end of the mall … it would only take us 10 minutes to walk over there and you could save $10. Would you walk over there to save $10 on a $500 suit? Most people would not. But that’s irrational, because it’s the same distance and the same $10 … it’s a matter of expectations.
If I see a fellow developer who is about my age, I automatically assume he is as experienced as I am. If I saw his resume and the fact that he only had 2 years of C# / .NET experience I may be a little shocked. It’s not because I’m discriminating against his age … heck, that fellow is the same age as me! I might be a little shocked because it’s not what I expected. However, if I saw a 24 year old with 2 years of .NET experience, I might be more inclined to consider him a good candidate. I happen to know a fellow my age could write code equally well, and I’m willing to bet that he would be a more mature co-worker.
So what’s the problem? Expectations. Thus, the cognitive bias older developers with less experience face.
So, how do you overcome the cognitive bias of your age not matching up with the expectation of your experience?
I assure you, all is not lost.
Follow “Plan B”
I don’t need to repeat myself … just do what I said here in the “Plan B” section.
It applies doubly for you. You have to become “so good they can’t ignore you”.
Likewise …
You Can’t Afford to Just Know “A Little”
Zebu said he had a “basic knowledge”. I’ve always found it hard to gauge what that means. What exactly is “basic”, “intermediate” or “advanced”? Don’t know, don’t care. But I do know this: you can’t be satisfied to have a “basic knowledge” about C# or C++. Don’t be satisfied with a basic knowledge. Identify those areas that you have not yet mastered and focus time and energy understanding those ideas inside and out.
Recently, when async was introduced, I realized I sorely lacked a fundamental knowledge of parallel programming, threading, etc. Furthermore, I wanted to master async, not just understand from a practitioner’s perspective that “Oh, when I see a method with an await keyword, that means I need to add the async keyword. If it returns a value, I have to wrap it in a Task
.” No, that wasn’t enough. I needed to understand it as deeply as I could … how it works, how is it different from working with threads or the Task Parallel Library. It spent three weeks (over 100 hours) researching, reading books and articles, writing little examples until I felt like I could explain it to anyone. That was important to me. I hate feeling dumb. Don’t be satisfied with a “basic knowledge”.
Beyond learning a programming language, modern developers need to invest themselves in patterns, processes and important frameworks (and API’s). THERE ARE NOT ENOUGH HOURS IN THE DAY TO LEARN IT ALL, so you have to know a little about a lot, and a lot about one or two things.
A few years ago I read Atul Gawande’s book, The Checklist Manifesto: How to Get Things Right
Things ALL C# Developers Must Know
At a minimum, you must:
(a) Know a lot about C# (or your chosen language), particularly about object oriented programming
keywords and concepts (static, base, override, overload, inheritance stuff, etc.), LINQ and now async features
(b) Have a solid grasp on the .NET Framework Runtime, the compiler, garbage collection, reference versus value, etc.
(c) Be familiar with the .NET Framework Class Library … know the major namespaces and what they’re there for, etc.
(e) Know basic architectural ideas like layers, the development lifecycle, etc.
(f) Know basic patterns like dependency inversion, SOLID, etc. (These lead you to a deeper
knowledge of object oriented programming, btw.) You simply need to be exposed to these … understand when it makes sense to invert / inject your dependencies, how to apply the ‘S’ in SOLID when designing your classes and methods, etc.
You should also read this book:
Framework Design Guidelines: Conventions, Idioms, and Patterns for Reusable .NET Libraries (2nd Edition)
Specializing In One Area
From there, you must go deep in one of the areas below. Essentially it breaks down into families of API’s, processes, tools, patterns, etc.
(d) Back-end web development – Know ASP.NET MVC 4
(e) Front-end web development – HTML5, CSS3, JavaScript, JQuery and other popular JavaScript libraries
(f) Client-side Windows development – Windows Presentation Foundation and patterns like MVVM
(g) Creating persistence layers using the Entity Framework, Linq to Entities, SQL Server, etc.
(h) WCF, web services, securing web services, CQRS, etc.
… and probably something else I’m forgetting.
Also, this list changes often. Part of “mastery” is knowing the current state of the technology, tools, processes, patterns, etc. AND keeping up with the changes. In another blog post, I’ll give you my secrets on how to accomplish this.
Achieving Rock Star Status
Down the line, I think you add to your core language knowledge …
(i) If you really want to stand out, add a unit testing framework, Domain Driven Design, Agile processes and project management, Gang of Four Design Patterns, a mocking framework, a dependency injection container, etc. to the list.
I realize my lists (above) sound like a lot to learn, but here again … companies don’t want to train you. Period. They want someone who can hit the ground running, ready to contribute from day one. You have to prove you already have the skills to do the work, even in an entry level position.
Furthermore, I would focus on the 80 / 20 rule and how it applies to software development and the topics above. (This may be a gross over-generalization, but …) For most of these technologies, there’s a core set of foundational knowledge you must master because the concepts, keywords, methods, etc. will be used often. However, beyond the essentials, for most languages, API’s, etc. there’s a bulk of information that’s edge case; it exists only for certain special situations, and you can research on an as-needed basis. This is the crux of my “buy versus lease” approach to learning.
Soft Skills and Interviews for Mature Beginners
If you are older, you’ll be expected to be an (informal) leader even if you have less experience. You can never *take* that honor, it must be given by the people around you. So, when you interview, you have to seem honorable. The way you build immediate respect is through your appearance, through your calm demeanor, the weight of your words, your trustworthiness, your work ethic, your humility, your confidence, your truthfulness, etc. You’ve met polished people before, right? Mirror them. Be genuine and friendly. Don’t be afraid to laugh, even if it means laughing at your failures. Project an attitude of helpfulness, not superiority. That comes across in interviews as well as it comes through on the job.
If you’re asked about the switch to software development from a career path in, say, systems engineering, find an elegant way to expressing how you feel this was a logical path. “After working as a systems engineer for the past 10 years, I realized that to support the applications I was assigned to within my organization, I needed to have a more fundamental understanding of the applications themselves. After all, at 2AM, I might be required to trouble-shoot the servers and bring them back online and I may not have the help of the developers at that time of day. I take a craftsmanship approach to my work, so it was important for me to really understand how they worked which lead me to reading their code. I would ask questions and make suggestions, and eventually I came to realize that I understood the system and the source code very well, and even developed a passion for it. That lead me to where I am today, and I feel like I can bring a perspective to my work that most software developers I’ve met don’t — I see both the development and implementation sides. I realize the importance of building exception handling and recover-ability into the software to ensure a good end user experience. Blah Blah Blah.” (Don’t say it if it isn’t true … you have a good story … spin it to explain WHY software development makes sense as a logic next step in your professional career.)
I guess what I’m saying is you shouldn’t hide your experience … embrace it and find a way to weave it into a description of your evolution as a professional. Wield your varied experience as a sword, don’t try to rid yourself of it like an albatross. Have examples ready of technical problems you solved in both your previous life and in your limited software development experience.
Other tips …
You’re going to have to be better than the other candidates to overcome the possibility of the cognitive bias I described earlier. This takes many different forms, but it centers on how you’re perceived during all communications and touch-points.
In no particular order …
Nobody wants to hear a hard-luck story. No one wants to hear about your health problems. No one wants to hear your war stories. Definitely don’t talk money, benefits or vacation time. That will iron itself out if you are the right candidate.Communication skills! Write and talk like and educated person, not lIk a prsn hu iz stil n hI skul. OMG! ROTFL! 
Read, re-read, and run all written communications through a spell check and grammar checker.
If you are conducting a Skype interview, make sure the room is quiet — banish the family and pets. Make sure that you are dressed professionally (button-down collared shirt, dress coat, no tie), make sure your background is well lit, and make sure that what is behind you is not distracting. A bookshelf behind you makes you look smarter than you really are. Hey! Wait … forget you heard that!
If you’ve been invited to a live interview, wear a suit. Suits are cool. Even if you know it’s a business-casual environment, wear a suit. You can dress down once you have the job.
Younger candidates often lack these essential people traits preferring the “Bro-grammer” / frat-boy persona. Eschew that in favor of professionalism.
Don’t let a harsh technical interview crush your will to live. Take notes during the interview (or brain dump afterwards) and research the answer to the questions you were asked. They can fool you once … don’t let them fool you again!
Have you considered a temporary / contract position?
Having trouble getting traction as a full-time developer? Maybe instead of a full-time position, you could get traction in your particular area of the world by going contract. Companies don’t always want the long-term liability of a full-time employee. Once they realize they can’t live without you, you’ll have a long-term offer. If not, there are many other companies in need of your new found experience and expertise. Also, some contracting companies offer all the benefits you would get from a full-time employer.
Plan Your Work and Work Your Plan
Plan your evolution towards software development as a career the way you would plan any serious undertaking or project. Generously pad timelines so you don’t feel guilty for not hitting some of your initial dates. Be realistic in your expectations … things ALWAYS take longer than you hope. Software development is hard and you have to forgive yourself if your energy doesn’t live up to your plan.
If possible, set aside two blocks each day of 1.5 to 2 hours of uninterrupted study time. If you can’t do that, set aside one block each day. That might require you reset family expectations, work schedule and sleep schedule. Dedicate yourself to it for 3 to 6 months. It took me a year of nights and weekends, but I was able to eventually teach myself Visual Basic after graduating college with no marketable skills. Too bad I didn’t have a LearnVisualStudio.NET back then
Don’t get impatient. Put in the time. Focus on the process and the learning, not on the ultimate outcome. Focus on building something tangible — a project to be proud of that can demonstrate your skill. Suppliment your project(s) with videos, books, articles, etc.
Trust that this process will work. It will take time and a lot of energy, but it will work.
You don’t need to get every job offer, just one. You don’t have to convince everyone you’re worthy of that first full-time software development position … you just have to convince one hiring manager. That takes a lot of pressure off.
Constantly Evaluate Your Progress
Be honest with yourself as dispassionately as possible. “Do I really understand this idea? Could I explain it to someone else?” Don’t simply blow past important concepts … take the time to stop and grasp it, even if it throws a schedule off. People who work slowly and deliberately have a better understanding. Resist the urge to simply copy-and-paste-from-the-internet to build your apps. These people get rocked in interviews because they lack a fundamental understanding of the concepts and technologies involved.
“Does this app really demonstrate my best work?” When you’re building those practice / example apps, don’t leave features undone. Pour over and obsess about the quality of the work. This will be a tool for you in the interview process so you want it to represent your best work.
Wrapping Up
That’s all I can think of for now. Any suggestions from you guys? What advice would you give to someone who is approaching software development as a second career or getting a later start?
