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!

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.

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…

I can always seem to tell the developers who are accustomed to working on new projects and those that generally work on legacy codebases.

When I run into a bit of legacy code that is giving me trouble or just need to vent, the ones who often work on new code or maybe are the only developer at their company always seem to give the same sorts of feedback — very little of which is helpful. Sometimes I might be asked, incredulously, why such-and-such design choice was used in the first place. (Who knows? I didn’t write it. I’m just tasked with adding functionality to it, integrating with it, etc.) They after a bit of back-and-forth, the recommendation is inevitably a full rewrite, starting from scratch in technology ‘x’, using methodology ‘y’, or framework ‘z’. Honestly, it’s so adorable they think that a complete rewrite is always the answer… Especially when it’s a long-lived application used day-to-day by the business to make money.

The developers that work a lot on legacy code, though, they get it… They know it takes finesse to slightly tweak the code here and there in just the right way to make things just a little bit better as things go, without potentially breaking stuff for the end-users.

Legacy code is generally this thing no one wants to touch, know one really understands, and everyone is afraid to break. It won’t be using the latest sexy new technologies. The code will all be written with more anti-patterns than best-practices. But so what?

Businesses are there to make money. They aren’t there just because they don’t want developers living on the streets… A lot of the time, the most cost-effective business decision is to keep the legacy system running for the least amount of money. Doing a full rewrite just so it’s in some other language or framework isn’t attractive to the business. They just want it to solve a specific business problem. That’s what I’m there for. I make things work.

That all being said, it drives me nuts when the most junior of development staff get tasked with code maintenance. I get that most people don’t want to work on that stuff, but skill and experience will generally serve you better in that situation, whereas new code (that likely isn’t even getting used yet) is probably a much more forgiving place to let the new developer cut their teeth on some business problems…

Maybe I’m just an outlier, though. I mean, I do really enjoy making systems from scratch. But I think there’s something to be said for the thankless job of being able to look at someone else’s code (and, as all developers know, everyone else’s code = ugly code), rolling up your sleeve, and saying, “I’ve got this…”

The draft specification for NIST 800-63-3: Digital Authentication Guidelines is out for review.

After researching and studying the prior ‘best practices’, it was decided that it just wasn’t helping as much as people thought.

Apparently, trying to get a person to remember the password “fMf43@%HZk%$#” without writing it down wasn’t working as well as people had hoped. Who would’ve guessed…? ;)

The new focus is on user-friendly password rules. Instead of having to follow some archaic combination of character requirements (which are often fairly arbitrarily decided upon), the shift is now mostly just towards longer passwords/passphrases. The minimum is now recommended at 8-characters (which is still barely anything) and the recommended maximum is at least 64-characters… Nice!

One piece of the recommendation I appreciated was that the passwords should supports unicode characters. Maybe it won’t impact that many general users in the US, but it definitely adds extra potential difficulty for attackers trying to brute force their way into accounts…

Also, they recommend comparing the password against known bad choices and then prevent users from setting their password to that. Periodically refreshing a list of the ‘x’ most common passwords from breaches, leaks, etc. and using that for the comparison would likely satisfy that… It’s already something I felt should be a no-brainer, but I’m glad it’s now part of an official recommendation.

Additionally, passwords should be hashed, salted, and stretched.

My favorite, though, is that passwords shouldn’t be expired unless there’s valid need to do so (like evidence of compromise, user request, etc.). This couldn’t make me more happy. It drives me nuts when a site forces me to change my password every, say 90-days “because reasons”…

All in all, it’s a lot of good advice. I hope at least some of it will get adopted by more non-government sites, services, and companies.