Thursday, 23 March 2017

Migrating away from VB.NET

According to the 2017 Developer Survey from StackOverflow, the outlook is pretty bleak for VB.NET… Out of all of the professional developers that participated in the survey, only 6.1% responded as using VB.NET (compared to 38.7% who responded that they used C#).

For the languages developers most dread working with, VB.NET was chosen by 77.2% of the respondents, under VBA at 80.4% and VB6 at 88.3%. Clearly there’s not a whole lot of love for Visual Basic…

That’s pretty sad.

I grew up using ‘basic’ languages of one form or another, so it’s kind of bittersweet that VB.NET has such little support these days… Not like the writing hasn’t been on the wall for years and years, of course… but still…

Looking at it from a purely pragmatic approach, though, it’s definitely time to move on. As a developer, there’s a definite financial incentive to it — I can get more jobs as a C# developer and I can get paid more money for it. That’s a no-brainer. And from a company perspective, I can understand why folks would prefer C# over VB.NET… There’s more talent to choose from, for one. Plus, whether true or not, there’s a stigma to VB.NET developers that they aren’t as skilled, aren’t as intelligent, etc. It’s hard to sell yourself as innovative, a market leader, etc. while having a product written in VB.NET…

Thankfully, I’ve already done some small projects in C#. There are some annoyances with it (case-sensitivity being the primary one…) but nothing too major.

One thing I noticed, though, as I looked at the stats is that even C# has been consistently dropping down in the survey stats every year. So that’s probably something worth taking note of… It could just be a self-selection bias from the types of folks on StackOverflow that are participating in the surveys, too, though…

Really, the biggest challenge I face is not so much the underlying language I use as much as just the architecture. It seems like desktop apps are a dying breed. The exception seems to be in the healthcare industry, but who knows how long that will remain true… Yet another thing I need to give some thought to, but I’ll save that for another time (and another blog post…)

Monday, 6 February 2017

Mindfulness Monday

One habit I’ve tried to develop over the years is to periodically update a list of my accomplishments. Not only does this make it easy to refresh my LinkedIn profile or resume but if I’m unable to think of recent accomplishments, it’s a good sign that I need to refocus myself and ensure I’m taking on the right projects (and not simply knocking out simple work orders as a way of killing time).

While that method has served me well over the years, I feel like it can probably be improved upon.

Instead of just updating my accomplishments ‘every now and then’, maybe I should increase the frequency a bit and make it a bit more deliberate…

With that in mind, it would also probably be worthwhile to be proactive in my accomplishments as well. Instead of just passively waiting for a meaningful project to fall in my lap so I have something to write about, I think I might start giving myself some small goals as well, so I have something worthwhile to work towards in between my other tasks.

Every day (or at least every week) should always have a few good accomplishments. And I think the more aware of them that I am, the more motivated it may make me for having an even better day or week the next time.

Saturday, 7 January 2017

Mentorship

There are two great ways to refine your skills — You can either learn from a mentor or you can mentor someone else. While the former is likely obvious, the latter might not seem very intuitive at first. But when you are tutoring someone and giving them guidance, you will generally need to have a very deep knowledge of the subject matter (at least if you want to do a good job).

I’m fortunate in having one or two friends who have expressed an interest in learning how to program. They don’t have high aspirations — they just want to learn the basics. But as I work with them, I realize that I’ve been pretty lucky in my development career. I’m largely self-taught. And though I’ve got a proven track record of being able to solve problems for the business, it wasn’t until I started teaching others that I began to see some of the gaps in my own knowledge. It’s very humbling.

Additionally, every few years I do practice interviews in order to stay in practice but also get a feel for what companies are currently looking for. This has been a great way of keeping my ego in check, for sure. As a ‘passive candidate’ who is generally not actively looking for new employment, I’m not typically as attractive to a company as someone who has no job and is desperate for work. Generally, companies have enough of a candidate pool that I don’t have to worry much about getting too far down the interview process. But some of the questions I’ve been asked from hiring managers gave me enough of a pause that, afterwards, I delved into the topic a lot more than I would have otherwise. Anything can be used as a learning experience that you can grow from — even just a quick phone interview!

Wednesday, 7 December 2016

Craftsmanship

There’s something to be said for the ‘just ship it’ mentality, where you focus on core functionality and get it out the door and in front of eyeballs. But the often-neglected skill is going back to what’s been done and adding those subtle bits of nuanced UI improvements.

When I’ve been working on an interface and catch someone using some aspect of it that wasn’t explicitly explained (and, as is often the case, was never directly asked for) because they inherently thought it would make sense and just sort of expected it, I love that. Or if they didn’t expect it but were pleasantly surprised to find it already there when they needed it, even better.

Paying attention to small details is something I’ve always done. Even when reading a book from a seasoned author, if I find a typo, I let them know about it. Similarly, I try to develop and encourage that type of behavior in new/junior team members as well. Do the field names match the modern jargon or do they use older/deprecated names? Is there anything visually that seems out of place, like a difference in font or alignment? My general philosophy on that sort of stuff is that if I notice it, someone else probably has (or will), too. And even if they aren’t consciously aware of it, I’m just they are at least slightly aware of it on some level… A lot of it comes down to judgement calls, which is often a weak area for less-experienced team members. But making the wrong choice and learning from it is a much better way to gain experience than just doing nothing (or simply being oblivious to it completely).

Ideally, every project or task being done should be treated like it is the only thing you will ever be judged by. Even the most boring and tedious of projects can be made more interesting and challenging that way.

Saturday, 12 November 2016

Improvement Instrumentation

We all like to assume that the applications we work on are getting better each and every time we sit down in front of the IDE and start banging out code for it. But how do you really know? Code metrics help with that. You can see how coupled your classes are, the cyclomatic complexity, and that sort of thing. As you go, you can look at the historical stats vs the current stats and (hopefully) see an improvement, which suggests greater maintainability down the line. Great.

But what about personal metrics…?

Despite how quickly technologies change, it’s easy to grow complacent and for skills to stagnate.

So how do we detect these weak spots and build up our resilience and proficiency in our skills?

In a team setting, I’ve helped increase our collective skills by implementing what I’ve called “Developer Fight Club”. It might be a simple algorithm or a full-fledged application, but the end result is someone will be deemed the winner and the rest of the participants are able to learn from their mistakes (or the successes of others) in order to perform better next time.

On a personal level, though, it feels a bit more difficult… Over the years, I’ve used all sorts of goals and metrics. Number of tickets closed, average duration between work-order assignment and resolution, frequency of blog posts on this site, number of development books I’ve read each month, etc.

There are definitely large gaps and flaws in the information you can get from any one of those values, but I think if they are looked at collectively, it can at least give me a more objective look at how engaged I am, more than I might be aware of on my own.

And, really, that’s what I think has the most impact for me. If I’m fully engaged in my development work, I naturally will want to put in the extra effort. Conversely, even if I’m learning new technologies or applying new methodologies, I won’t get much out of it if I’m just going through the motions…