After the shooting that happened last week and the subsequent revelation that online forums may have contributed to that bowl-cut-weirdo’s radicalization and subsequent rampage, several people I know have approached me to ask what website owners with discussion boards could have done that could have prevented radicalization. There are some options, but I’ll warn you, most of them are pretty terrible and have a tendency to be easily circumvented (or to backfire spectacularly). The architecture of the internet is intended to be able to route around damage (it was designed to assist with communications after one or more nuclear strikes, after all), and censorship mimics damage in an architectural sense. So, most fixes are not particularly useful, although there are some options.

’ve been developing in JavaScript for a long time and have seen client side techniques evolve drastically over that time. However, I have to say right now is about the most frustrating (and promising) time to be working with JavaScript in a professional capacity that I’ve seen in many years (and possibly ever). Let’s do a little retrospective of what I recall from back when I started really getting into computers.

Having started my training as a programmer in the 90s with 16 bit Visual Basic 4 and having seen them at their worst on several occasions, it’s often easy for me to take the side of people who don’t like the company (except Apple fanboys, because their platform has exhibited a lot of bad, anti-competitive and destructive behavior of late as well and more recently). I’ve seen them destroy competitors, build up a huge userbase on a platform that made building applications easy and then torch it on the altar of progress, and even keep security-hole-riddled crap around for years that caused compromised systems and grief for users for decades. Consequently, I’ve tried on numerous occasions to switch to linux, and ended up coming back to windows (usually after some config file got hosed and cost me a day of work). I’ve lived through ODBC database access, DAO, RDO, ADO, ADO.NET, Linq-to-Sql, and Entity Framework (whose early versions drove me to use NHibernate). I’ve seen ActiveX in the browser, VB webclasses, silverlight, and even FoxPro. I’ve even used Visual Source Safe…. I’ve essentially had a love-hate relationship with Microsoft for a very long time.

Someone pointed out to me the other day that I am a bit of “an old fart” in the .NET development space. At first, I was about to protest and insist that I wasn’t that old. Then it occurred to me that I have been using .NET since the first public beta, which came out in 2001 (if I recall correctly, which I may not, because I’m old). That said, as I think back over my career and the loads of developers who eventually got out of the industry, I wistfully contemplated giving some advice to the folks just getting started. The reasons for it are many. First, I want to see more people succeed. Second, I’ve watched loads of people fail (or worse, not rise to the full level of their potential), including screwing up via self-sabotage. Here, then, are some things that I’ve noticed that might serve as “lifehacks” for making your climb through your career a little easier as well as making your survival more likely.

Apologies to all for the lack in posting. Life got real busy around the tail end of September as we moved to a new house and really hasn’t slowed down since. That said, I think things are finally easing back up where I can get back on track with regular blogging.

Sometimes, the truth is remarkably annoying and not what you told yourself it would be. So it is with managing website, both your own and those of others. People talking about these things often seem to be doing so with rose-tinted glasses on, as you’ll discover that it doesn’t all work like that. Here are some things I’ve learned on my little journey through being a webmaster.

So, I’ve been blogging for a bit and finally got something I had hoped to receive for a while, that is, some questions from a reader. In this particular case, the reader was a friend who called to ask the questions on the phone, but I thought they were darned good ones and took notes. I think committing them here is a good idea because if one person is asking a question, it’s a good bet that others are too. Further, it’s an excellent way to generate a bit of actually useful content based on what readers actually want to know, which is often a hard thing to discover, since readers tend to stop being readers if they don’t read things that are useful to them. I didn’t quite get the exact questions down, but I got enough of a gist that I think I can answer a few. I’ve thrown in a few others as well that have come up casually in conversations with other friends, as I kept the list until I had enough items to make a post out of it. Some of these I didn’t completely answer during the conversations in question because I kind of wanted to chew on them a bit.

Probably at least once every couple of weeks, I get into (sometimes heated) discussions with other software developers about their careers. I see so much helplessness, so much hopelessness, and so much dependence on others and it’s all entirely unnecessary.

So, it’s time I said some things that need saying. It’s time to smash some ugly, easy lies so that beautiful, subtle (and often difficult) truths can flourish. It’s time for me to have THE TALK with you (no, not that one, this one). It’s time for me to tell you why you are absolutely nuts as a software developer not to be making progress towards self-employment. After more than a decade in this industry, I can tell you that the best time to have gotten in business for yourself is five years ago. The second best time is right now. Below are some very good reasons. It may sound like I’m bashing employers; I’m not. It’s just that their concerns and yours are increasingly not intersecting. As a consultant, that is fact number one in your mind; as an employee, it should be, but is easily ignored until it can’t be ignored.

All healthy companies are much alike; all dysfunctional ones are dysfunctional in their own way. For instance, every healthy company I’ve worked at has fairly consistently spent time and effort to make sure their employees are appreciated and productive. They’ve spent time involving the employees in the process, giving them workable goals to progress towards, and generally making sure that their people are taken care of so that they can take care of the company. And while such stability is laudable and makes the places fun to work, if you really want the good war stories, you have to work at a dysfunctional place.

It’s pretty common for developers to disagree on the role of comments in source code, sometimes in a rather vehement manner. I think at least part of the problem comes from a fundamental misunderstanding, in that most developers simply don’t explain well what they mean when they talk of well-commented code. I believe there are multiple types of code comments, of varying value in different stages of a project and I also suggest that when disagreements come to pass over comments, it’s largely because developers are using the same word to describe very different things. Here are the types of code comments I commonly see and what purposes they serve well.