image_pdfimage_print

JIT Learning

When I first entered the field of software development, in order to become a so-called expert, we needed to learn a handful of technologies. It was challenging, but it was doable.

This is no longer possible.

Today, we need to be able to apply JIT (just-in-time) learning techniques to keep up. It’s just not possible to learn everything about a single tool, much less every tool we’ll need to use on a given project. In Microsoft’s .NET framework alone, there are over 10,000 classes as of this writing. If you’re a .NET C# Web developer, you need to have at least a working knowledge of the .NET framework, the CLR, Visual Studio, C#, HTML, JavaScript, CSS, Windows, IIS, SQL (no matter what engine), and the specifics of a particular SQL engine. And in most systems, you may need to understand another handful of technologies, core concepts, and third party tools.

So when do you learn all of this? Just-in-time.

You can accumulate knowledge of the core technologies over several projects, yet still only touch the surface. And rarely does a new project come along where you wouldn’t need to learn at least one new technology you’ve never touch before, or may not have even heard of before. For example, on my latest project, I added Twitter Bootstrap, Telerik’s KendoUI, and Dapper to my arsenal. In addition, I’ve explored Font Awesome, and LESS for incorporation into a future release. I’ve also expanded my JavaScript and jQuery knowledge to make better use of those.

So how do you keep up with all these tools and technology? Well, you can anticipate everything you’d think you’d need to learn, but aside from a few educated guesses, you’d have to be a clairvoyant to keep up with the changes in our field. It’s often like using a waterfall SDLC. I don’t think it’s really works anymore. There are too many unseen forces working just under the radar, and you’ll constantly be blindsided.

How do I keep up with this stuff? Just-in-time learning. For the most part, I learn as I go. Since most new tools we need to use build upon the core concepts we’ve built up over our experiences, the learning curve is usually not so large for adding something new. Part of my strategy is using supplemental learning to build up that core skill set, which I’ll discuss as well.

This is my current strategy for learning. Since we all learn somewhat differently (in our own combination of kinetic, visual, and auditory resources), your mileage may vary:

  1. Research: Unless you have a team leader assigning which technologies to use on a project, you’ll likely be involved in researching the best solution for a particular requirement. For example, we wanted to start our project by using a framework to help drive the look and feel of our web apps, so we started comparing such tools. We decided upon Twitter’s Bootstrap framework. I watched intro tutorials, read reviews, viewed sample code, and experimented with the samples.
  2. Video (Passive): Once I’ve decided what I want to learn, I usually start by watching a series of videos on the topic. Pluralsight is easily my favorite choice for an intro of some of the most common technologies and tools, although more obscure or new tools may not (yet) be covered. YouTube is another great source for such tools. Of course, strongly supported tools may have their own video tutorials, although I usually find those lacking. It seems to be an afterthought for a lot of companies, and production is often poor or inconsistent. Since, in my role as a consultant I’m expected to be an expert on the tools I’m using (unless a new technology is dictated by the client), I normally use my breakfast time before business hours to watch these videos. It allows me to absorb myself into the technology in a passive manner, which helps get me acquainted before diving in hands-on. If you’re lucky enough to attend a local user group meeting on the topic, that’s also a great way to get an intro as well as allow for direct Q&A. But it’s rare to have such perfect timing, unless the technology you’re about to use is the new “flavor of the week,” and the rest of the world is learning about it at the same time.
  3. Video (Active): Although I’m still in more of a passive state of mind at breakfast, by lunch I’ve usually been in coding mode, so this is a good time to re-watch parts of the video and actually try out some of the examples being discussed. Although video is great for pausing and rewinding, it’s a bit awkward to pinpoint the exact locations of what you want to re-watch, so if example files are available for download, I prefer playing around with those. Be careful, though, since it’s too easy to have the examples do the work for you, since they’re usually already fully written. Without the hands-on (read: typing in yourself), it usually won’t sink in as quickly.
  4. Google / Bing == Stack Overflow: As you play around with examples, you’ll likely have some questions that aren’t yet explained by the point you’ve reached in the video course. I normally find that it’s easier to search for answers to my questions instead of trying to find it in the tool’s documentation (if it even exists). Since the best search results usually end up at Stack Overflow, I spend a lot of time reading answers there. Keep a close eye on the timestamp of the answers, though. They may be outdated. But if it’s a good answer, it may also have a direct link to the part of the documentation you’ll need.
  5. Web Articles (Blog and Otherwise): When it comes time to dive into a specific piece of the technology I’m trying to use while learning, I start focusing on specific online articles. Several years ago, I’d save and read magazine articles. Well, I mainly saved with the expectation that I’d eventually find the need to read some of those articles. I’d say that happened with 5% to 10% of those articles. But we don’t even need to do that anymore. Since many articles are available online, allowing for random access, the magazine is truly obsolete. I still subscribe to a couple, but I think that’s mainly to hold on to the memories of a foregone time. Besides, I’m sure they’re making the font on those things smaller every year. Or it’s my eyes :) Seriously, I’d often start an article in a magazine, only to finish it online.
  6. Books: With all this JIT learning, there’s still that nagging feeling that you could be doing things better. I feel like that all the time, and it used to bother me. No longer. I’ve learned to become more pragmatic over the years. Job # 1 is to deliver a solid solution, making it as maintainable as feasible. But refactoring should be built into subsequent work, whether or not you do some refactoring during the TDD (or otherwise, unit test) process (if your shop encourages that — which it should). This is the time to supplement your knowledge with a deeper understanding and best practices in the technology and tool you JIT-learned. This is where books become useful to me. Even if a book is inherently a bit outdated, it’s still useful, because core concepts and best practices live longer than specifics. I rarely read technical books cover-to-cover anymore. I may read a few introductory chapters, but then I’d skim through specific chapters based upon where I’m focused.
  7. Deep-Dive Videos: But I usually reach for a detailed video course instead of a book. Although Pluralsight has some deep-dive topics in addition to their introductory tutorials, I feel the TekPub videos complement them quite well, and focus more on the deep-dives. They’re usually opinionated, and they often focus on best practices, and make you really understand the topic in ways you’ve never thought of before. Watching someone code and think out loud at the same time is often as valuable as pair programming. Both sites (and there are others) are well worth the investment in your future.

In between my JIT learning cycles, I spend those free hours supplementing my knowledge with deeper dives, as I described in points 6 and 7, above. I use those breakfast and lunch sessions to fill in any gaps, and do some soul-cleansing refactoring in subsequent sprints based on that learning. Such exercises helped me become a better C# and JavaScript coder over the past year.

I also use the off-cycles to learn other technologies I predict with some certainty that I’d be using within the next year or so. For example, learning MonoTouch, MonoGame, and XNA in anticipation of implementing some app ideas and starting a new venture.

As developers, our education will always be an ongoing process. There is just so much to learn. We must develop a strategy just to keep up or get ahead of the game, yet remain current and productive. Although your strategy may differ from mine, hopefully I’ve provided some ideas to get you started.

image_pdfimage_print

Technical User Groups – The Tribe of Passionate Geeks

Happy 10th Birthday, INETA!The bug got me in the mid-70s. My math teacher in junior high, Mr. Blumenfeld, introduced us to a fascinating contraption on a tall stool that appeared, at first glance, to be an adding machine of some sort. But the thing was programmable, and came with this very nifty manual showing all the instructions you can program into it. I was mesmerized. He’d pull out the machine once a week and give a lesson on it. But an incident by a couple of students led him to punish the entire class and terminate those lessons. It was pretty devastating, especially since it had triggered a passion that has stayed with me through now.

It wasn’t until I entered high school two years later that I got my first taste of a “real” computer. I was introduced to BASIC by my programming teacher, Mr. Saperstein, on the Wang and Olivetti desktop machines. I strongly preferred the Olivetti, because it was a lot sleeker than the Wang, which was very “terminal” and plastic looking, and just looked a lot older. If I recall correctly, the Olivetti machine had a brownish casing, and seemed more modern. I made sure I started my projects on that machine so I had to be allowed to continue using it every class, since the disks where my projects were saved couldn’t be swapped between machines. We also had a Commodore Pet, but although the keyboard with all the strange graphic characters was interesting, students pretty much ignored that machine for some reason.

The first real program I wrote for class, of course, was a baseball simulation game, since I was always a huge fan. I spent hours at home creating dice games using stats from books, crunching numbers on the $100 calculator I got as a gift for my Bar Mitzvah (and which I STILL have to this day). That first programming project gave me an unbelievable feeling — to be able to create something out of nothing was so empowering!

I desperately wanted something to program at home. I wanted a home computer, but nothing was really available yet in the mid to late 70s (at least what I was aware of). But one day I noticed at a Consumers Distributing store that they were selling a programmable Texas Instruments calculator (TI-45?). When I finally saved up enough ($200?), I walked two miles to the store to buy it. I still have this somewhere. I came across it, along with its manual as I was cleaning out some old junk recently, but I have no idea where I placed it since.

In January 1980, a couple of months after I started dating my future wife, my parents gave me a choice. I can either go to Disney World with the rest of the family, or I can have my first real personal computer — a TRS-80 Model 1, with 4k of RAM and Level 1 BASIC. It was a no-brainer. First, the computer lasted a lot longer than the trip, and second (and more importantly), I had just started going out with Lorri, and I didn’t want to go away. This was one of the easiest and best decisions I’ve ever made. I’ve never looked back from either benefit.

In the early 80s, the vast majority of my time was spent with Lorri or the TRS-80. One day, while working as a keypunch monitor / programming tutor at Brooklyn College, a friend (and fellow TRS-80 user) came over to show me the 80-Micro magazine he subscribed to for the TRS-80. As I started skimming through it, I was shaking so strongly from excitement, it must have been visible to all those around me. This brought my little computer to a whole new level. I was introduced by the “community” of users to so many things I didn’t realize the machine was capable of.

Although this wasn’t actually a user group experience, it was my first taste of what being part of a larger community of “tribe members” felt like. I had discovered that there were many other people out there who shared my passion, and who I could learn from. It was addicting. I devoured everything about the computer, and all other computers in my life from that point forward.

It wasn’t until the late 80s that I had my first exposure to a real user group. A friend of mine brought me to the Clipper User’s Group at MLK High School on Amsterdam Avenue in NYC. Wow — these are my people! I was hooked. I went to every meeting from that point forward for several years, while Clipper was my primary programming tool, and met some amazing people. That group also kick-started me on getting my first commercial product released, when my business partner and I did our first demo at one of the meetings.

That group also became the model for regular team meetings I held for my consulting company throughout the 90s. We were all passionate about programming, and it was a way for us to get together to learn and discuss technology for technology’s sake — not just in a work environment.

When I closed up my company, and started working at my next job, I finally got involved full-time with Microsoft technologies. But because I worked far from NYC, I rarely went to user group meetings anymore. Occasionally, I’d attend a developer’s conference or something. It was a rare, exhilarating experience being around like-minded people in a learning environment. It continued to stoke the flames of my passion for programming. But as some of you may know from earlier blog posts, my career started to move away from programming into management during the mid to late 2000s. I’d try to get to .NET user group meetings in NYC, and still try to get to developer conferences (on my own dime, now that I was in management) as often as possible. But I started to feel like an outsider. I still felt like the attendees and speakers were part of my tribe, but I started to feel like an impostor.

Since I was unhappily in management, I needed to do something to keep up with the development world, as well as stay connected to what I considered my tribe. I did find a user group close to work, in Stamford, CT, but it was held with less and less consistency. It was getting more difficult for me to make it to user group meetings in NYC, but when I attended one in late 2006, I asked one of the leaders of the NYC .NET Developer’s Group, Bill Zack, if I could make an announcement. Although I had absolutely no idea yet how and where I could pull this off, I announced that I wanted to start a .NET user group up in Westchester, near where I lived. I mentioned that I’d make further announcements when it became a reality, and asked people to contact me if they’d be interested in a group in that area. It was after this meeting that Bill and Peter Laudati, the Microsoft Developer Evangelist in the area, made me aware of INETA (which is celebrating their 10th anniversary this month). They gave me some suggestions, including resources from INETA, for getting the group started.

I dug through the material, and my wife and I started looking for a local venue that could support such a group for free (since user groups are all virtually free for their members). We had very little luck. Most places wanted to charge, or required liability insurance. Sadly, I put off this idea for a while, still trying to get to the NYC meetings as often as possible.

In May of 2007, I was contacted by Bill Zack, who mentioned that Louis Edouard (who used to run the Stamford group at UConn, but was finding it overwhelming to do it all himself), and Leo Junquera, a fellow geek from the local business community, were looking to restart the group at UConn. They were looking for a third volunteer to help with the rebirth. I jumped at the opportunity. Since it was held close enough to Westchester as well, and was easier for local folk to get to rather than NYC, we decided to restart the group under a new name: The Fairfield / Westchester .NET User Group. We had our first meeting in June, 2007, and the rest, as they say, is history.

Since then, I’ve been heavily involved in running eight code camp events and two monthly user groups (we also run a SQL Server group at UConn). It’s been incredible. Not only am I living the dream of actively participating in a community of like-minded “geeks,” it’s also given me the confidence to get back into full-time development, and I no longer feel like an outsider impostor. This is my tribe, and we share a common passion. We love to learn, and our interest in development lives well beyond the walls of work.

Happy 10th birthday to INETA, the group which is instrumental in building our tribe of passionate geeks! If you’re a like-minded individual, and you really care about this field (and your career), I urge you to join a local user group. You can find one near you by checking the listings on the INETA site.

image_pdfimage_print

“Stuck” In Management, Cause #4: Misdirected Loyalty

This is the next bullet point in my continuing series on how you can find yourself “stuck” in management, and how to get yourself “unstuck.” In this post, we’ll talk about why the illusion of company loyalty somehow remains, and how you can recognize if it’s real or not.

Even in the 50s, 60s and 70s, I doubt it was pure company loyalty that kept people at a firm for decades. It’s always been loyalty to people that meant anything. And when people stayed with the same firm for many years, several people did, so the loyalty was more to each other than the firm you were with.

Don’t fool yourself. Companies have never truly been loyal to their employees. They have loyalty to the bottom line, and if they’re run well enough (and may have some of their original idealistic founders), they may continue to have some loyalty to the product they produce. Again, people may have loyalty to co-workers, but that’s really it. It’s the remaining humanity left in most companies that portray any sort of loyalty.

But these days people can remain loyal to each other while still moving around. Social networking and the ease of communication helps. Besides, staying in one place out of an illusion of loyalty isn’t really helping your co-workers if you are unhappy.

The typical career path in corporate (fill in your country / region here) is a move from tactical to strategic roles. But many of us who excel in tactical activity suddenly find ourselves in an exclusively strategic role (not to mention the baggage peripheral tasks that seem to go along with a strategic role). It appears that even in the early 21st century, most companies still don’t know what to do with experienced tactical stars. After all, the only way to bring on new talent is to push existing talent up the corporate ladder, or to fill those positions through attrition.

If you think about it, much of that attrition is from people who wake up and realize that if they don’t make at least a lateral move, they may wind up in a job they hate through earned appreciation and promotion.

Have you ever noticed that your technical teams tend to make the same mistakes over and over? Have you also ever noticed that your team seems to reinvent the wheel again and again?

I believe we’re missing a critical role at most companies – the role of a true technical lead. Even architectural roles tend to move into hands-off positions, despite the opinion of many, who feel that the best architects remain hands-on at some level. Besides, corporations vary widely in their definition of an “architect.” By the time a top developer has gained critical technical and business experience, he or she is bound to be pushed into an eventual hands-off role, simply because “that’s the way it’s always been done.” And the world loses significant talent.

If you truly believe in the product or service your company provides, and if you feel you have an enlightened management team, try to put together a solid argument for a technical leadership role for yourself (architect or otherwise) – a position that will keep you hands-on, while still giving you “corporate recognition and perks,” if that means a lot to you.

But even if you have such a management team, who understands the value of an experienced leader on the front lines, recognize that corporate culture is very slow to change. So give yourself a deadline of six months to a year. And if you see the expectations of your role drifting towards 100% strategic, or just managing people and timelines, yet you still love coding, consider it time to move on. Otherwise, years will disappear. Trust me.

Next time, we’ll start discussing some of the signs that may tell you you’ve made a horrible mistake.

image_pdfimage_print

“Stuck” In Management, Cause #3: The Temporary Commitment

This is the next bullet point in my continuing series on how you can find yourself “stuck” in management, and how to get yourself “unstuck.” In this post, we’ll talk about how you may find yourself filling a “temporary” management role that somehow became more permanent than you had planned.

You’re dependable, reliable, and a natural leader. One day your manager calls you into her office, sharing information that has not yet been made public.

“We had to let Joe go today.”

You’re a little stunned at the news. “Oh, wow. I knew there were issues, but I didn’t realize it was that serious.”

“You know how hard it’ll be to find his replacement,” she continues. “We know you want to stay hands-on, but you’re one of our most senior people, and we really need you to help us out here until we can find someone else.”

Being an ethical and loyal professional, you immediately respond from the gut. “Of course I can help out a little while. Did you start the search yet?”

“We’ve reached out to a couple of agencies, but we’d really love to promote from within. I was hoping you’d be happy in the position and consider it for yourself.”

Due to that sense of obligation I mentioned in my prior post, you’re tempted to agree to try it out. But you shake yourself out of your stunned state just in time to remind her how you really want to stay technical.

“I understand,” she replies somewhat disappointedly, and then goes on to tell you about a management meeting that afternoon to discuss the transition.

And that’s just the first sign the desire to look for a permanent replacement is dissipating.

Through nobody’s fault, months go by and the “temporary” arrangement is forgotten. You appear to be performing well, because, well, as a consummate team player, you know they’re depending on you.

This is extremely dangerous. It’s the boiled frog scenario. You missed the chance to jump out of the water when the topic was first broached, and now you’ve gotten used to it. And so has your boss.

At this time, you either give in and stick it out, or you’ll need to leave. A clean break is needed, because by this time, it’s way too late to go back without it becoming a demotion.

There is no easy solution in this scenario. You didn’t want to leave your company hanging at a critical time, but as stunned as you were at the original news, you needed to pause and think things out. Two lessons: 1) A sudden request should not trigger a spur of the moment career decision. Take at least a few hours to absorb everything before giving an answer, and prepare your reasons for turning it down. 2) Never, ever let months, or even weeks go by without following up on their replacement plan, and to remind your manager that this was just temporary, explaining why you’re value is higher in your prior role. Don’t make it sound like you’re turning down a promotion. Frame it with what they’d be losing by moving you out of the role that you did so well for them.

Next time, we’ll talk about loyalty, and what that really means these days.

image_pdfimage_print

“Stuck” In Management, Cause #2: Time to Climb the Corporate Ladder?

This is the next bullet point in my continuing series on how you can find yourself “stuck” in management, and how to get yourself “unstuck.” In this post, we’ll talk about how you may start convincing yourself that management is where you should be at some point in your career.

If, like me, you’ve been in the programming business for a decade or two, you may start feeling influenced by well-meaning (but often ill-informed or assuming) people around you who suggest that at this point in your career, you should be “climbing the corporate ladder.” Likely, you’ve earned their respect over time, and they’ve witnessed you take on ad-hoc mentoring and leading opportunities. So they may assume that you’ve been too caught up in your day-to-day development duties to realize that it’s time to make, what is traditionally seen as, the next “natural step” in your career.

Or perhaps you’ve felt a bit burned out by two or three recent projects, coding non-stop for days on end, ridden by management to “get this project done already!” You start wondering if maybe you should finally step into their shoes and leave the coding and long, bleary-eyed hours to the next generation of young whippersnappers. Out with the old, in with the new. Have to make room for the new coders, right?

Or perhaps you’ve felt the pressure of a growing family, with kids soon to enter college, wondering if the only way you can pay those huge bills is to accept that promotion your CTO has been trying to push you towards, with all the extra frills and benefits (the golden handcuff kind). Or you start wondering how you’re going to stash enough away for retirement on a developer’s salary. After all, you’re closing in on that age, right?

Well, I went through all of the above. And because of those, along with other circumstances in my life at the time, I eventually found myself in management.

I broke a promise to myself that my 20-year-younger self swore I’d never, ever do. It was so, so easy to make that promise 20 years before. I loved coding, and pictured myself happily doing it for the rest of my life. Hell, I even dismissed the thought of ever retiring at all. I mean, who would want to stop coding simply because he or she didn’t need to code anymore for a living? We’d live off our life savings, and I’d write programs that I wanted, or wanted to sell on my own, and not worry about any deadlines. Coding without deadlines – now there’s a dream worth working towards!

I even realized early in my career that there wasn’t really a technical career path laid out in the corporate world, so I knew I’d simply avoid ever being in that position by going into consulting. I knew from year one in the field that consulting was what I’d be doing very soon.

But maybe if I delayed my entry into the consulting market, I would have avoided the naïve paths that eventually led me into management. Is delaying that move a lesson everyone should follow? I’m not so sure. Maybe my tale of caution can help your awareness of the risks you may face, so that you can take a different path than I did.

Do not think that management is a natural step for a mature professional in any field. It’s an old tradition for an older world that simply does not ring true today. Yes, management is the right path for many, but in my belief management is a career in itself. It is not simply a “next step.”

We have so many more career options these days. If you want to remain on a technical path for your entire career, there are several enlightened companies that respect and reward that these days. And if you don’t want to work just to make someone else’s passions and dreams come true, start your own software company. But like I mentioned in my last article, plan it out where you can outsource the stuff you don’t like to do, so you can spend most of your time on the technical stuff.

Or take the consulting plunge. Developers can do very well financially as a consultant. Of course there’s risk along with flexibility, but so much has been written on the topic. Educate yourself before diving in, and you’ll be able to manage the risk and keep doing what you love to do. Programming. My all-time favorite book on consulting is Aaron Erickson’s “The Nomadic Developer”. This book is a goldmine in so many ways.

And you can build a thriving business on top of consulting. If you plan well, you can add training to your repertoire, as well as create opportunities for multiple streams of income. That is a must, if you want to continue increasing your income without having to bill 24/7.

One of the most exciting things for me about getting back into consulting is that not only does it keep my skills fresh, it hones a set of skills that open an amazing number of doors in today’s world. Everything runs on technology. Between app stores that make it easier than ever to monetize with minimal investment, and the ability to use your skill to help start the next great world-changing product, there will always be need for skilled hands-on developers and architects.

And do not worry about the fear mongers screaming that all development will eventually be offshored. Suffice to say, that is a topic unto itself. But bottom line, there is tremendous need for highly skilled developers near wherever you happen to live, especially for those who have strong communication skills as well (also a topic for another time).

There is no reason at all to buy into the belief that management is where you should end up, especially if it’s not for you.

Next time, we’ll talk about the so-called “temporary” management trap you can easily get yourself caught in.

image_pdfimage_print