This is the archive of my blog, which used to be hosted on my personal site. It originally had about 650 posts but I removed almost half of them, either because they were outdated, no longer relevant or because I just didn't see any value in the content anymore. Feel free to browse through the archive, or you might want to check out the following pages specifically:
- New Here? : a categorized overview of my better posts
- Categories : a list of all of the categories of posts
- Recommended books : a list of books that I recommend to software developers
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 :)
Written by Davy Brion, published on 2012-05-14 23:08:36
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.
Written by Davy Brion, published on 2012-05-13 20:50:36
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.
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.
Written by Davy Brion, published on 2012-05-06 16:36:10
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.
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 2012-04-09 16:04:48