It's Not About The Number Of Hours You Put In

There's been a lot of talk on twitter about the 501 Manifesto. Be sure to read it if you haven't, because it's got some very good points, though I don't like the dig at people who contribute to open source since these people are having an ever increasing positive impact on our jobs. Anyways, the manifesto is about being a software developer without being defined by it. I actually think it's a healthy point of view.

I've always disagreed with this seemingly popular point of view or opinion that every developer should spend a lot of time outside of his/her working hours blogging or publishing their code on Github or contributing to open source. Those activities can be important but aren't necessarily so and the people doing them aren't inherently more valuable or important than developers who choose not to contribute to open source software or who don't feel the need to make a name for themselves. I also disagree with the notions that developers who are only involved with software development during their 8 working hours a day must be inferior or that they can't be passionate about it or that they'll never be great at it or any of that other crap that you'll sometimes hear people say.

I know some great developers who put their code out there and/or their thoughts by blogging. I also know some bad developers who put their code out there and/or their thoughts by blogging. I know some great developers who aren't involved with software development outside their working hours. I also know some bad developers who aren't involved with software development outside their working hours. There are good and bad developers on both sides of every situation you can come up with.

I think it depends a lot on what people do during their 8 working hours. Can we really say that developers who work 8 hours a day on challenging projects with strong co-workers in teams where knowledge is passed around continuously are missing out on anything if they don't really spend any other time on software development outside of work? That just doesn't make a lot of sense to me. If I look back on my own career so far, I've typically been rather passive outside of working hours in periods where I felt like I was working on cool things, where I was challenged, where I was learning a lot on the job. Conversely, I've always been much more involved with software development outside of work when I was working on things during working hours that I didn't find challenging or interesting or where I wasn't learning anything new. I'm guessing that this holds true for a lot of people, though certainly not all.

Of course, if you're not working on interesting things or continuously learning and improving on the job, it's your own responsibility to make sure that your skills and insights stay up to date. You don't have to put in the effort to do that, but if you don't, you don't really have a reason to complain either when you're not happy with the kind of work that you're doing. Your employer is not responsible for your career and your future, you are.

And if you are working on interesting things and continuously learning and improving on the job, you don't need to pressure yourself to do more outside of your working hours because certain people in the community say you should. A lot of people get involved with blogging and open source with the hope that it'll end up leading to more interesting work in the long term. Who knows, you might just be a step ahead of them already.

Written by Davy Brion, published on 4/19/2012 9:35:18 PM
Categories: opinions , workcareer

Microsoft And Open Source: Hoping For Better Collaboration

By now, you've probably all heard that Microsoft is moving to an open development model for ASP.NET MVC and some other ASP.NET projects. Even though the source code of ASP.NET MVC has always been available under an open source license, its development followed a closed development model. This meant that outside contributions weren't possible, nor were we able to follow the actual commits in the MVC source code repository. With the recent announcements, this is no longer the case and I think this is fantastic news. It finally enables collaboration between Microsoft employees and people outside of Microsoft on a strategically important Microsoft product. This is good for Microsoft as well as the open source .NET community.

I hope that this newfound appreciation for Open Source within Microsoft will lead to another huge improvement in collaborative development in the open source .NET community. While Microsoft is now open to accepting contributions from the community, it would be a tremendous step forward if Microsoft would also contribute to other prominent open source .NET projects in the future. In the past, we've seen numerous open source .NET projects become popular and widely used. And unfortunately, Microsoft responded to some of those projects by producing their own libraries and frameworks that basically do the same thing. Except that, for most of those projects, they never quite matched the quality of the open source projects they were inspired by. If only all of that effort spent on duplicating already existing libraries would've been spent on improving what was already there, the entire .NET community would've been better for it.

I'd love to see a Microsoft that works with open source developers and encourages them, instead of trying to duplicate their efforts whenever they feel they need to provide their own library or framework for something that's already covered by a superior open source alternative. These duplicated projects only alienate people that at one point were passionate enough about the .NET platform to work on improving it for free, in their spare time. These are the people that Microsoft needs to cherish and nourish instead of competing with them. Microsoft has shown some interesting signs of better understanding of open source development and collaboration in the past year or so. Here's to hoping they take that critical next step as well.

Written by Davy Brion, published on 4/9/2012 4:04:48 PM
Categories: opinions

Thoughts On Learning New Things

Jef Claes published an interesting post about his preferred way of learning new things. There's one part in the post that I don't entirely agree with:

I like to believe learning should be a hands-on activity as well. Basically, stop consuming, start producing. Don't get me wrong, I do think there is value in reading blog posts (I might be slightly biased on this one), reading books and watching videos, but I find that this value is marginal compared to what you gain by actually doing it.

Hands-on activity (producing) is certainly a very important part of any learning process, but I wouldn't go as far saying that the value of reading books/blogs (consuming) is marginal compared to that of producing. In fact, I believe their value to be pretty equal. I've seen too many people who start producing simple things, and then think they've got a pretty good grasp of the technology they're using and then move on to producing more complex or bigger things without actually knowing enough of the technology they're using to support the more complex or bigger scenarios. The results certainly aren't always pretty and I'm sure each and every one of you has seen this scenario unfold with at least one developer you know. Probably more than that even.

I think in a lot of cases, people start the producing phase perhaps a bit too early and then in their enthusiasm of seeing things working sort of skip the more boring consuming that could've benefitted them a lot. Once you've started producing, you need to keep consuming regularly. A tremendously valuable part of any learning experience is getting feedback and insight from minds that have more experience with a given subject than yours. If you're lucky, you can get this from your coworkers. If you're not that lucky, you'll need to find other sources and books, blogs, videos, user group meetings, etc can be a great way to fill that void. And even if you do get to learn a lot from your coworkers, it never hurts to learn more from the experiences of others outside of your immediate circle, if only because their situations and constraints will differ from yours as well.

The other very important part about consuming is really getting to know the technology you're trying to learn. I've always found it very important to at least get an idea of how things work internally within a technology that I'm using. You certainly don't need to know all of the implementation details but just having an idea of it can really help you avoid a lot of problems once you need to use a technology in a more advanced way than in your initial experiments. Most importantly, it should give you better insights as to whether you're using the technology properly, which unfortunately isn't always the same as getting something working. And as a bonus, you'll probably learn about features you won't immediately need but knowing that they're there can save quite a bit of time and effort later on. Just imagine the improvement of the signal-to-noise ratios that you'd see on mailinglists, forums, and StackOverflow if everyone took the time to get a better grasp of the technologies they're using.

When I start with learning new libraries or frameworks, I usually start off by reading most (and often, all) of the official documentation of the technology before I even get into building something myself. If I want to learn a new programming language I'll look for the most recommended books for that language and buy one (or more, if I wasn't satisfied with the first one). I won't even start using the language until I've gone through the book. Once I feel like I've got a pretty good theoretical grasp of the technology, I start building something with it. I also start looking for good blogs on the technology and subscribe to them. I'll also start following influential people of the technology on Twitter. And I just continuously try to soak up as much knowledge as I can from people who're doing more impressive things with the technology than I am. At first, you might not understand everything they're talking about but after a while, things just start clicking and you're getting a really good grasp of things. None of this is a substitute for learning from producing, but it certainly is an incredible addition to it. And one that makes a world of difference, IMO.

Written by Davy Brion, published on 3/11/2012 9:22:23 PM
Categories: opinions , workcareer

How Do You Pick Open Source Libraries?

I'm currently looking into which library I'm going to use to handle authentication in a breakable toy project. Now, despite it being just a breakable toy, I want to do it with as few constraints on technical quality as possible because I want to maximize the learning experience I'm going to get from it. That means I don't just want to quickly put something together that just works. I want something that works, but that would also hold up in real world scenarios, even though the project will at best only be used by myself. Which means that I'm going to be picky about any libraries that I take a dependency on, just as I would if this were a project that I'd be getting paid to work on.

So as I was browsing through a few possible alternatives for my authentication needs, I started thinking about my thought process when evaluating libraries/frameworks to use. I generally base my decision on the following items, listed in order of importance (to me).

How well does it work for my scenario?

If a library satisfies all other items on this list, that certainly doesn't mean it's an automatic lock. How it works and the impact it has on my code is definitely the most important factor.

Popularity

I've noticed that I let the number of watchers/forks on sites like Github influence my opinion. If a project has many watchers and many forks, odds are high that there's a relatively large group of happy users as well as people involved with the project. It also increases the odds that the project will be around for a while. Of course, inactive Open Source projects often remain available as well but if nobody's working on it, I'm not exactly tempted to take a dependency on it. Log4net is a notable exception to this, obviously. But when a project has a lot of people interested in it, or better yet, contributing to it, it's a good sign that you'll easily get help if needed, it's only going to get better in the long run and that it might get forked should the original developers stop working on it. As the author of an Open Source project that doesn't have a lot of watchers/forks (Agatha), I'm aware that my point of view on this is rather hypocritical but hey, it is what it is.

Code quality

I don't have the time to do an in-depth review of the code as I'm sure most of us don't do either. But I do like to glance over the code to get a general feel of the quality of the code. I focus mostly on the clarity of the code and also keep an eye open for sloppiness or downright WTF's. I guess the questions I'm mostly trying to answer when doing this are: "is this code I'd like to try to improve or fix if I need to?" and "how easy would it be to debug this when I need to troubleshoot some non-obvious issues?".

Location of code and issue tracker

A lot of people will probably take issue with this, but I consider it to be a major plus if the project is on Github. Not just because of my personal preference of Github, but because they truly encourage people to collaborate and contribute to projects and they make it very easy to do so. Also, the site is fast! I cringe when I have to look over issues of projects on Codeplex because it's just terribly slow. And the UI doesn't come close to that of Github either. I've heard that Bitbucket is pretty similar to Github, but I've never even looked for projects there. In any case: I want to be able to download the latest version of the code at any time, or of a particular branch if I need to, as easily as possible. I also prefer an issue tracker which is fast, responsive and easy to search. It doesn't have to be Github, but those 2 requirements are important to me.

License

If it's GPL, I don't use it. Also, I check whether or not a commercial license needs to be purchased when you want to use the library/framework in production. Pay attention to dual-licensed projects because that Open Source license might not apply to commercial/production use!

I'd love to hear your thoughts on this. Did I miss any important factors? I just quickly put this post together so it's likely that I missed some good ones :)

Written by Davy Brion, published on 1/16/2012 10:15:40 PM
Categories: opinions , software-development

Blue Pill vs Red Pill

I've been somewhat critical of certain 'hot' MS technologies on Twitter this week. Particularly: Azure, Nuget and Entity Framework, and I didn't even bother to complain about the troubles I've had with the differences between 32-bit and 64-bit Powershell today. And I've noticed that whenever I voice a negative opinion on a Microsoft technology that is considered cool or great, I lose a few Twitter followers. My reaction to that is: good riddance. I prefer losing a few followers because of it, than having to deal with the responses from certain fanboys who either haven't stepped outside of the MSDN world, or are just trying to impress others with a devotion that they're hoping will increase their status within their organization or within the Microsoft developer community in general.

A lot of people think that I'm anti-Microsoft. And I'm really not. I'm not anti-anything. I am pro-quality. I have high standards because I've seen and experienced high quality solutions elsewhere and when I have to deal with lower quality alternatives to those solutions, I tend to compare them, which is only natural. If Microsoft releases good stuff, I'm more than happy to use it. I even considered creating an Entity Framework training course, similar to my NHibernate training course, because I was hearing many good things about it. But after trying to deal with a certain Entity Framework problem that came up this week in the one project at work that uses Entity Framework, I couldn't help but think "I don't want this mess in my life, no matter how much money I could make with it". I sincerely want to use good Microsoft technology, but too often it just disappoints me. And that in itself, isn't much of a problem since there are plenty of good Open Source alternatives around. What I do consider to be a problem is the reaction that many people have when you're critical of Microsoft technology.

I've often compared it to living in The Matrix. A lot of us are living in a world where they are being pushed into believing something that just isn't true. And some of us at some point get to choose between taking the blue pill or the red pill. The blue pill symbolizes blissful ignorance of illusion, while the red pill symbolizes the sometimes painful truth of reality. A lot of developers in the Microsoft world choose to keep their eyes closed and blindly believe whatever Microsoft tells them to believe. They'll run into a variety of problems with the technologies they've been told to use but a lot of people just accept it for what it is because they don't know any better, or because they're scared of the seemingly harsh world that awaits them should they choose to ignore Microsoft's guidance and venture out into a world that is more chaotic, yet offers more possibilities and flexibility. If you take the red pill, you learn a lot about what's really possible yet you face the added burden of having to deal with the people who've picked the blue pill and even worse, the technology that comes with it. Because that truly is the only bad part about taking the red pill. You'll start taking some things for granted, and when faced with technologies that don't quite match up to what you've recently become used to, you will get frustrated because of it. After all, you know things can be done much better with less friction, yet here you are, dealing with problems that have been solved by other libraries/frameworks already. That is the only sour taste you'll experience after having swallowed the red pill.

The choice between the blue pill or the red pill is one that everyone has to make for themselves. And honestly, I can't be bothered anymore to try to convince people to take the red pill instead of the blue pill. I've learned to adopt a "whatever floats your boat without sinking mine is fine with me" attitude, but sometimes, I can't help but wish for a world were people would try to think just a little bit more for themselves instead of blindly following what a dominant entity is telling them to do or use. Look around, see what other people and communities are doing and honestly ask yourself "are they doing things better than I am?". And if they are, put in the effort to figure out why and how they're doing what they're doing. The worst thing that could possibly happen is a temporarily sour taste, and there are many ways to wash that away.

Written by Davy Brion, published on 12/15/2011 9:44:40 PM
Categories: opinions

« Older Entries