work/career

The Non-Typical .NET Job

I recently referred to an interesting .NET job as a 'non-typical .NET job'. I hadn't used that term yet up until that point, so I thought that was rather interesting. But what exactly do I mean with 'non-typical .NET job'? It's pretty simple really: a job where you're using .NET technology without blindly following the guidelines, recommendations and software from Microsoft on how to develop software on the .NET platform. It basically means that you'll use whatever you think is most appropriate for what you're trying to do.

The biggest problem in the .NET world is that most companies that do .NET development just stick to what Microsoft tells them to use and how to use it. Many .NET developers largely focus on that, because they know all too well that it increases their odds of getting hired. And let's face it: Microsoft has a solution for practically everything. The only problem is that those solutions are rarely the best in what they're trying to solve. But hey, no manager gets fired for going with Microsoft, right?

The result is that there are too many companies and too many developers that focus only on what Microsoft offers. But there's a lot more to software development than what Microsoft offers, or even knows about. There are countless examples of Microsoft being late to whatever technical party is interesting at the time. And when they show up, they certainly don't always make a good impression.

If you're the kind of developer that likes to learn from what other software development communities are doing, odds are high that you're screwed. There is an interesting OSS community within the .NET world, and they frequently produce great solutions, quite often based on succes stories coming from other development communities. The problem is not that .NET developers don't have great solutions available to them. The problem is that the majority of them simply don't know about them only because there hasn't been any Microsoft hype about it, or that the devs who do know about it aren't allowed to use it because their managers are sceptical about it, most likely also because there's no Microsoft backing for the technology or architectural style that is being proposed.

I'm not advocating the avoidance of Microsoft products or solutions. By all means, use Microsoft products if they are indeed the best solution to your problem. But do be aware of the things that are getting attention outside of the Microsoft sphere and use them when it makes more sense to use them. That's the essence of the 'non-typical .NET job' and that's exactly what makes it interesting: using the right tool for the right job.

Developers Need To Keep Challenging Themselves

7 commentsWritten on October 23rd, 2011 by
Categories: Opinions, work/career

I read a very interesting article about a study on why some people learn faster than others. It's a very interesting read which I highly recommend, but in case you're short on time I'll summarize the most important parts because they're relevant to the subject I want to cover with this post. The study claims that there are 2 types of mindset when it comes to learning:

  • The fixed mindset: People who have this, think that we have a certain amount of intelligence and can't do much to change it. To them, a mistake is a failure, a sign that their capabilities aren't up to the task.
  • The growth mindset: People who have this believe that they can get better at almost everything, as long as they can invest the necessary time and energy. They see mistakes as an essential precursor to knowledge, the engine of education.

Needless to say, people with a growth mindset turned out to be significantly better at learning from their mistakes. The article also covers a very interesting experiment involving school children. The children were given a test, and half of them were told "You must be smart at this". The other half was told "You must have worked really hard". After that, they could choose between 2 new tests. The first one was more difficult, but came with a mention that the students would learn a lot from them. The other test was similar to the test they had just taken.

And here's where it gets really interesting: of the kids that were praised for their effort instead of their intelligence (I'm going to refer to this group as the effort-kids from now on), 90% of them chose the harder test. Of the kids that were praised for their intelligence (I'm going to refer to this group as the intelligence-kids from now on), the majority chose the test that was similar to the one they had just taken. Presumably, to avoid risking a low score after having already been praised for their intelligence. After the second test, all of the kids took the same third test, which was the hardest one so far. The effort-kids worked hard at figuring out the puzzles, while the intelligence-kids were easily discouraged by their mistakes. After the third test, the kids were given the choice to look at the exams of kids that did better than them, or the exams of kids that did worse. The effort-kids generally wanted to look at the exams of the people who did better. The intelligence-kids mostly picked the exams of those who did worse. The final test had the same difficulty level as the initial test. The effort-kids raised their average score by 30%, whereas the intelligence-kids saw their average score drop by 20%.

I find that kinda stuff fascinating. It also kinda confirms what I've seen from fellow developers ever since I graduated and started working. Every good developer I've met isn't afraid to make mistakes and sees mistakes as learning opportunities. These people routinely challenge themselves by learning something new. They also keep an eye on what other people are doing to get better and they actively try to learn from people they consider to be better than them.

One guy I used to work with was considered to be a great developer a few years ago. Now this was the kind of guy who was not only used to being praised for his 'intelligence', but his self-confidence was largely based on it. He once told me his favorite class in high-school was math because the other people in his class thought it was hard, while it was easy for him. He actually said it like that. When other people started getting more attention for their technical skills and knowledge, he began to move away from coding and started focusing more on writing functional analysis documents. He wasn't bad at it, but it wasn't great either. Now he does a little bit of everything from what I've heard. I'm pretty sure that if his self-confidence wasn't based on the praise he gets, he could've been much better at whatever he wanted to do.

That's just one story but I've seen similar things with other people who seemed to be more interested in what other people thought of what they could do as opposed to actually trying to improve on what they can do on a continuous basis. If they start thinking rather highly of themselves because of the praise they get, they often start thinking it's just not necessary anymore to keep working on improving their skills.

Keep challenging yourself. If you think you're pretty good at what you do (and there's nothing wrong with that), make sure you keep searching for new and better ways to do what you do. And when people praise you for being good at what you do, don't let it get to your head because before you know it, you won't be getting much praise at all anymore.

You Need Your Time Off

3 commentsWritten on October 3rd, 2011 by
Categories: life, work/career

One of the hardest parts about being a good developer is trying to keep up with all of the new stuff that comes out. Let's be honest: we all have a list of things that we'd love to learn more about, but we just can't get around to it, right? I'm talking about programming languages, frameworks or libraries, new techniques, new kinds of data storage, architectural styles, or maybe just certain tools like specific editors or whatever. Well, I'm sure you get the point. I have a list like that. And so do you.

Another difficult part is always having a list of things you want to do, or need to do. Implementing that pet project you've had on your mind for a while now. Contributing to some Open Source projects that you're fond of. Accepting pull requests. Writing a blog post about something. There's always something, and you never quite manage to cross off every item on that list. I have a list like that. And so do you.

And you know what? That's ok. You have to accept the fact that between your job and your personal life, there is a limited amount of spare time available to you. And you just can't spend all of it on learning new stuff all the time or working on things that you think are important. Sure, learning is important. And so is taking the time to work on things that matter to you. But what's equally important is giving yourself enough time off to sit back, relax and maybe even do nothing.

I spend about 80 minutes each day on the train. Sometimes I'll read. Sometimes I'll code. And sometimes I just listen to some tunes while I stare out the window, either thinking about nothing or thinking about whatever comes to mind. It's a conscious decision. That's me saying "I just wanna relax right now". Which means I don't even want to think about software development stuff, or blogging, or anything else that I'm supposed to do. On some free evenings I think "damn, I really should do something useful". And on some of those nights, I will. But I'll also consciously choose not to do anything useful from time to time as well. It all kinda depends on how busy I've been in the days leading up to that free evening.

Your brain is like a semi-intelligent battery. It has a limited amount of energy and it can only do so much between charges. It's smart enough to scale down its activity when it's starting to run low, but most of us are too stupid to realize it and we just try to keep going. The result is that whatever we're trying to do, we're not going to do it as well as we think we are. You will have trouble learning new things when you're running low. You certainly won't do your best work when you're running low. In fact, you're likely to do a half-assed job which ironically only increases your workload.

Take care of that battery. Recharge it regularly, and don't think you can get by with minimum recharging. If it doesn't work for your phone, it won't work for you either.

Maintaining Bad Code Can Be A Great Experience

12 commentsWritten on September 4th, 2011 by
Categories: Opinions, work/career

Nobody likes to maintain a bad codebase. And still, it's an experience that i'd recommend to every developer, particularly early on in your career. People who are relatively new to coding usually don't have a good view yet on what kind of code will cause pain in the long run, and what kind of code won't. And if you keep getting assigned to new projects, you're less likely to develop that view properly compared to someone who has to maintain an existing, problematic codebase.

We've all heard the most common ways of improving as a developer: read the right books, learn from more experienced people, and above all: practice, practice, practice! And all of that is indeed very important. But i've always felt that being exposed to bad code and having to deal with it can be a tremendously important and valuable learning experience as well. As valuable as repeated practice, reading and following advice from experienced and skilled developers is, none of it will stick with you as long as the pain you feel day in, day out from working with a bad codebase.

When you're working with a bad codebase, it's important to figure out where the pain comes from. Whenever you experience pain while trying to make a change, or while trying to implement a new feature, take a bit of extra time to look for the cause of the pain. Then try to think of a way that would avoid the pain entirely, or at least lessen it. And if you can, implement your solution in the codebase. If you can't, try the approach you thought of in a personal project. If you do this routinely, you're going to learn a lot about what works well and what doesn't. I'd dare say that you'll get a better view on this than people who never have to work with legacy code, since they rarely get exposed to the long term problems caused by the code they write.

CV Likes And Dislikes

2 commentsWritten on July 31st, 2011 by
Categories: work/career

Last week, i posted the following tweet:

Bart De Keersmaeker replied with an interesting question:

I don't read a lot of CV's in my current job (in this case, i was just filling in for someone else who was on vacation), but in my last job i did a lot of technical screenings and have seen more than my fair share of CV's. I don't really have a 'number 1 item' that is guaranteed to get your CV in the 'must-interview' pile. But there are things that i love to see on a CV, and there are things that i absolutely hate to see on a CV. While reading this, please keep in mind that i am a developer and that my opinions of what makes a good CV are most likely entirely different than those of recruiters (since most of them just scan for buzzwords and specific technology mentions). If you let this influence your CV, don't complain if it actually makes it harder to get through the recruiters. But i do think that once (if?) your CV makes it into the mailbox of a developer, it should improve your odds.

Dislikes

  • Mentioning every single technology/framework/library you've ever worked with. Keep in mind that less is more. Just list the important ones. There's no point in providing a lengthy list of stuff that nobody is using anymore. Also, group them into categories (languages, ORMs, IOC containers, testing frameworks, etc). Believe it or not, that is a very easy way for you to show that you can at least categorize them, which is something that many people who list every single thing they've ever used aren't often capable of doing. Grouping them in categories also indicates that you're aware of the concepts behind them, which gets my hopes up that you're the kind of developer who can easily apply his knowledge of those concepts to similar frameworks/libraries/tools/whatever which you may not have used yet. Also, don't list anything that you don't feel comfortable answering questions about. Always assume that you will be questioned about anything that you mention.
  • Mentioning every single project you've ever worked on. Again, less is more. Mention the important ones and describe them briefly (a couple of sentences at most). If they weren't very interesting (and that's not necessarily a reflection on your abilities so don't be afraid to be honest about this), just list them as 'various forms-over-data applications' or something like that. I'll know what it means, without having to read the same thing over and over again and i will appreciate the honesty.
  • Repetitiveness in job descriptions. There's nothing wrong with mentioning your role on the projects you've worked on (actually, please do so!) but keep it short and don't make it look like a copy/paste job (unless you're only listing the role). There's really no need in repeating the same responsibilities and tasks over and over again, and it sort of indicates an inability to communicate efficiently.
  • Dogmatic statements. I love opinionated developers. It's an indication that you're serious about your job and usually (though not always) shows a level of passion. However, if i get the impression that you're incapable of compromising, don't expect an invite. If you're going to be working with other developers, i need to know that you are capable of putting your own preferences to the side in favor of any team-preferred solution. I want you to be open about those preferences, but if there's a "my way or the highway"-vibe, i'd be reluctant to have you come over for an interview.
  • Bad grammar and spelling. If i get the impression that you couldn't even take the time to proofread your CV, i'm going to assume you're unlikely to do so with your code before you commit it, or mails before you send them.
  • Unexplained overlapping dates. Be sure to explain any overlapping dates between projects and assignments. Every time i see overlapping dates without an explanation, i can't help wonder whether it's a mistake or not. A CV should not contain mistakes, because that's another sign of sloppiness.

Likes

  • Mentioning Open Source contributions. It shows that you're passionate about what you do which unfortunately, is rather rare. It also gives me a chance to check out your code which is always very telling. Also, if you have a GitHub account it definitely makes sense to list it. It not only gives me access to the code you published, it also allows me to see how you interact with other developers if you get contributions to your code or submit contributions to other projects.
  • Mentioning community involvement. Giving talks, going to (or helping with the organization of) conferences or any other developer focused events, blogging, etc... mention it, even if it's just 'small' stuff. In the case of blogging, be sure to include a link to your blog as well. All of this stuff shows that you care about improving as a developer.
  • Listing your favorite technical books and/or what you're currently reading. Another good indication that you're willing to invest some of your personal time to improving as a developer. It also provides a good look into your technical interests, which can lead to interesting conversations during an interview.
  • Keeping things short and to the point. Nuff said :)

To be clear: i don't consider open source contributions or community involvement as requirements, but it certainly increases your odds to get an interview. It is however unrealistic to assume that everyone has the time for that or even wants to do that. There are plenty of good developers out there who don't contribute to open source projects or blog and i'd be more than willing to invite them for an interview if their CV avoids the Dislikes.