The Inquisitive Coder - Davy Brion's Blog | inquisitive: adjective. given to inquiry, research, or asking questions; eager for knowledge; intellectually curious

And… That’s All Folks

26 commentsWritten on May 14th, 2012 by Davy Brion
Categories: About The Blog

I started blogging about 5 years ago, and over the years I've published 653 posts. This will be the last one. I had some specific personal goals in mind when I started blogging, and I've gotten everything I've wanted out of it, and more. I learned a lot, and I'm happy with a lot of the feedback I've gotten over the years. But the time has come to move on. I want to get back to writing more code instead of writing about writing code. I've mostly enjoyed writing blog posts, but in the past year it has felt more like a chore than a hobby, so it's probably a good idea to just call it quits.

I'm not entirely sure yet what I'm going to do with the content on this blog. There's quite a few posts I surely want to keep around, but certainly not all of them. For now, I'm going to keep the blog up so everything stays available but after a while, I'm gonna shut it down. I might keep up some kind of static archive of my favorite posts, or I might just put them on GitHub in MarkDown format. If you have any suggestions on what I should do with it, I'd be happy to hear them.

I will remain active on Twitter and I plan to be more active on GitHub from now on. But the blogging thing ends here and now. I'd like to thank everyone for reading, especially the ones who've been around since the beginning. It's been an interesting ride for me, but it's time for something else

Why Things Don’t Work In Your World

1 Comment »Written on May 13th, 2012 by Davy Brion
Categories: work/career

A very common reaction for developers to have when they hear about new technical approaches or new approaches to team organization is "yeah right, that won't work in the real world" or "that'll never work in our situation". A lot of us have felt that way. I certainly have as well a few times in the past. The 2 most common excuses you'll hear for not believing something can work are:

The people I work with aren't good/talented/disciplined enough to make this work.
It can't possibly work in our organization.

The truth though, is that it's actually because of you. Whenever you say "that won't work for us" or something similar because of the people you work with, you immediately show your lack of faith in them. You might think that that lack of faith is justified, but that basically means you've given up all hope of making things better. You know it, and worst of all, they know it too. People who aren't trusted by their coworkers or superiors generally pick up on that rather quickly. Some of them will respond by putting in more effort and trying to do better. Others will become demotivated and wonder why they should even try because "it's never good enough anyway". At this point, your lack of trust in your coworkers becomes a self-fulfilling prophecy.

You might want to consider another approach. Think back on how you've responded to situations where you where challenged by coworkers or superiors but where it was clear that they trusted you and believed that you were capable of doing a better job. I'd bet that for most of you, it improved your motivation and your willingness to do better. It probably helped you bring out the best in you. You can use this to your advantage when you're trying to get better results out of your coworkers. It's quite simple really: it's all about how you approach someone. If you want somebody to do better, and you approach them in a positive manner you're much more likely to get better results. If however, they sense your distrust (and most people pick up on that quite easily), they will most likely be defensive or apprehensive. The odds are quite low that something good will come out of that.

If you want people to improve and do better, it's important to establish a culture where everybody knows that it's ok to make mistakes, and that every mistake is an opportunity for the whole team to get better. If that's not the case in your situation, what is preventing you from trying to get to that point? Even if you're not officially in a leadership position, there's no reason why you can't set the tone and be a leader. Start making an impact on one or two people and build off of that growth. Once you've got a few people convinced, it's much easier to bring the rest along with you. You don't need to shoot for the stars from the beginning either. Try to improve whatever it is you think needs improvement with small steps, in an iterative approach. Instead of thinking "that will never work for my team", think "we're not quite ready for that yet, but we will be someday".

If you believe you can't improve your way of working due to organizational reasons, it's important to also start with your team. It's easy for management to ignore the opinion of one person, but it gets progressively harder for them to ignore it as more and more people start asking for change. It's much easier to persuade management to try something new if you can show that the whole team believes it's worth a shot. Keep pressing the issue until you get the chance to try it for a short time. If you keep asking for it, management might just get tired of hearing it and who knows, they'll grant you some time to try it out. You'll never know if you stop trying.

Of course, you won't always succeed in convincing management or your coworkers. But you've gotta try. And if you keep hitting walls, you might actually be better off moving on to another job with other people instead of being frustrated in your current position. Even if you don't agree with what I'm saying in this post, you can't possibly disagree with this: not trying will get you nowhere.

Three Strikes And You Refactor

8 commentsWritten on May 6th, 2012 by Davy Brion
Categories: Code Quality

The first time you do something, you just do it. The second time you do something similar, you wince at the duplication, but you do the duplicate thing anyway. The third time you do something similar, you refactor.

That's a quote from Don Roberts, found in Martin Fowler's Refactoring book (page 58). That quote didn't really make me think twice at the time I read it, but it got stuck in my head later on when I heard it from someone who's always been very influential to me. When this person told me that this was one of his favorite rules, I was still in my "no way dude, all code needs to be as clean as it can be" phase. But it's really grown on me over the last few years. Now, just to avoid any confusion: this post is about my interpretation of 'Three Strikes And You Refactor', not about what may have been originally intended or what some people think of it now.

The most important thing I remember when learning about TDD was:

Write a failing test
Do the simplest thing that could possibly work to make the test pass.
Refactor.

With all the literature that's out there, as well as popular opinion on how important clean code is, it's tempting to go overboard with that 'refactor' step. It's tempting to go for the solution that is crispy clean. The solution that'll have your coworkers or peers go "ohhh, now that is nice". However, you really need to ask yourself the following question: "is it really worth it?". Wanting to make sure that every piece of code is perfect takes up a lot of time, and I've learned that it certainly isn't always worth it. Besides, it's quite easy to go off on a path of introducing new concepts and abstractions to your code that end up being totally unnecessary. If this increases complexity in parts that don't really matter, it ends up being a huge waste. Not only for the person who wrote it, but for every person who has to read it and comprehend it later on.

'Three Strikes And You Refactor' is a helpful rule of thumb here. Try to keep things as simple as possible and don't be afraid of a little duplication here or there. Once you find yourself (or a teammate) doing the same thing for a third time, it's worth cleaning up because that third time very often means that it wouldn't be the last time either. This way, you only introduce concepts and abstractions that are really needed, and enables you to avoid adding unnecessary cruft to the code.

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

8 commentsWritten on April 19th, 2012 by Davy Brion
Categories: Opinions, work/career

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.

Most Valuable Professionals? Give Me A Break.

29 commentsWritten on April 15th, 2012 by Davy Brion
Categories: Opinions, Rants, work/career

I've always been very skeptical of Microsoft's MVP award. Officially, Microsoft's MVP award stands for Most Valuable Professional, but its true meaning is probably closer to Most Valuable Promoter. The quality and integrity of the MVP's you know is probably dependent on the region in which you work. I work in Belgium, and over here the MVP program is, in my opinion, a joke. I'm going to discuss why I think it's a joke but keep in mind that this will depend on your region. I know that there are indeed great MVP's out there who do have professional integrity and true real world experience in some regions, but I certainly wouldn't be surprised if the state of the MVP program in Belgium occurs in other regions as well.

First of all, let's take a look at an image that Microsoft uses on its MVP page:

"Independent Experts. Real world Answers."

This is indeed what the MVP program should be about. It is however the exact opposite of what I and many others in Belgium have experienced. Let's cover the words in those 2 sentences a bit more in-depth.

Independent

Most of the .NET MVP's in Belgium work for a handful of companies that happen to be big sponsors of every important Microsoft event in Belgium. Now, could it be possible that the best .NET developers in Belgium all work for these handful of companies? I highly doubt it. I know a lot of great developers in Belgium and none of them work for these companies. And I'm quite sure that none of those people are less valuable or knowledgeable than any of those MVP's. In my experience, there is hardly anything independent about the Belgian .NET MVP's. Most of them got their first MVP award while they were employed by sponsors or 'strategic partners' of Microsoft. Most of them tout the latest and greatest Microsoft technologies, pretty much unquestioned, even if it means contradicting their statements and positions when they were promoting the technology that Microsoft wanted them to promote 3 or 4 years ago. And they're never openly critical of anything Microsoft-related out of fear that it will negatively impact their chances of being renewed as an MVP. They may not work for Microsoft, but they are anything but independent of Microsoft.

Experts

This is a tough one. What makes one an expert? In some fields, people are considered to be experts based on the amount of research they've done. In other fields, people are considered to be experts based on what they've actually done. I don't think I'm going out on a limb here by saying that in the field of software development, what you've done should be more important than what you've researched or read about. In my opinion, an expert in a specific technology should have built at least one, and ideally more than one, non-trivial system using the technology in question and should be able to tell you about mistakes they've made, things you should avoid, and should never use examples that promote bad practices. I rarely hear MVP's talk about things you should avoid. I rarely hear MVP's talk about mistakes they've learned from. I routinely see examples from MVP's that make me cringe. I routinely hear MVP's promote technologies even though they haven't actually built anything impressive with it. I think of a lot of words when I see examples or proposed solutions by MVP's, but the word 'expert' unfortunately isn't one of them. This also applies to the Microsoft Extended Experts Team by the way. I can only question the validity of such a team if it contains people who are listed as experts of a particular technology when I happen to know for a fact that some of those people have never even used the technology they're supposed to be an expert in in a real world project. Let's be honest here: most of the MVP's and the MEET members simply aren't experts. They are people who have a strong interest in a particular (or more) technology and do their best to promote said technology. There's nothing wrong with that at all, but there's a huge difference between that and being an expert in something.

Real world answers

This one cracks me up the most because most of the Belgian MVP's hardly work on real world projects. And when they do, they typically work on "multiple projects" as they like to say it. For anyone who's ever worked on multiple projects at the same time: could you honestly say that your contributions were truly valuable to the end result? Let me put it differently: don't we all know that people generally produce the best results when they don't have to juggle too many things at once and can focus on as few things as possible? You will rarely hear about a Belgian MVP working full time on a non-trivial real-world project. A lot of them get to spend a certain number of paid hours each week on 'community work', which means blogging, writing articles for magazines, creating presentations for events, etc. When they're not working on that, you'll often find them talking on Twitter about pretty much anything but interesting or demanding work. And of course, their employers will occasionally send them to clients for a bit of consulting here or there, or to do a product demo. Unless these guys are putting in 60 to 80 hours a week (which I seriously doubt), I'm having trouble figuring out when exactly they do the kind of interesting work on real world projects that would enable them to provide answers based on real world experience.

It also doesn't help that I've frequently heard rather unflattering stories about these MVP's from people who've worked with them. It's pretty much always the same: they're not invested into the project, they spend too much time 'interacting with the community' and if you let them go near important parts of the code base, bad things usually happen. Now, I'm not the type of person who simply believes everything he hears. In fact, when it comes to matters like these, I generally only believe the stories I hear from people of whom I'm truly sure that they know what they're talking about. And if you've been reading this blog for a while, you'll know I'm rather critical and that I set the bar rather high when it comes to that.

Lastly, my personal working experience with MVP's has been abysmal as well. I once worked for a client where we had to get rid of 2 people because of how bad they performed in real world circumstances. One of them was an MVP at the time, and now works at Microsoft as an Evangelist. The other wasn't an MVP at the time, but has been one for a few years now and is even one of the Regional Directors of this region. A few years later, I had drinks with a manager of the company they both worked for and he bluntly admitted that both of them are useless on real projects but that their MVP status was a huge benefit to the company from a marketing and image perspective. Not exactly the image or branding I'd be looking to put out there, but hey, to each his own.

Why On Earth Did I Write This?

For 2 reasons. I think this whole MVP thing sets a bad example to young and impressionable developers who aren't sure what to focus on to advance their careers. To outsiders, these MVP's sure look like they've got a great thing going and it's easy to see how that could impress people who don't know better. There are already quite a few developers who suck up to these MVP's in the hopes of someday getting to 'that level' as well. I'd much rather see these people put effort into learning about concepts that will last them a long time and building skills that are transferable to multiple technologies instead of sucking up to the wrong people, and trying to network their way to more interesting work because the work that results from that is truly mediocre at best. By all means, try to make a name for yourself by blogging and speaking publicly. But do yourself a favor and stay true to yourself and favor quality over quantity when considering the audience you want to target. Hey, it worked for me

The second reason is because this whole MVP thing is, in my opinion at least, offensive to the many dedicated professionals who give their all at their jobs as they work on real projects that matter, as they try to mentor younger developers in their workplace, as they try to optimize the way they develop software not only for themselves, but for their teammates and their employers or clients. These are your true valuable professionals.

I'm sure I'm gonna get a lot of flak for this post, but honestly, it won't really make any difference to me. The people who'll be offended are people I'd rather not work with anyway. And of course, I feel quite confident that I'll rarely, if ever, have to deal with these people in a professional setting since I'm primarily interested in interesting and demanding work

« Older Entries

The Inquisitive Coder - Davy Brion's Blog

inquisitive: adjective. given to inquiry, research, or asking questions; eager for knowledge; intellectually curious