I got a question this last week that I answered very briefly but I felt that to answer it completely would take a blog post. So here’s the blog post.
Should the author of a piece of code be responsible for more than just unit testing, or does peer review have a play?
Continue reading “15 Ways To Write Beautiful Code [That Have Nothing To Do With Testing]”
Several comments this week contribute to this week’s post.
The first, and the one that pushed me to write this post, is a discussion over at Simple Programmer on a post called “Cracking the Coding Interview” where I made the following statement,
Coding interview? Really? I wouldn’t bother. This is right up there with working 60 hour weeks for me. Yes, I know all the big companies do this, but it doesn’t make it right. “Just because you can, doesn’t mean you should.”
I’ve been programming now for 27 years. I started with DOS 3.1 for anyone who’s trying to figure out when that was.
I’ve NEVER had to do a coding interview and I make really good money so it isn’t that I’m working for minimum wage.
Here’s the deal. I can tell in about 10 minutes if another programmer knows their stuff.I can tell in about 10 minutes if another programmer knows their stuff. I expect that any company worth working for (and yes that includes even Amazon, Google, Microsoft, and the other big boys) should have someone on their staff who can do the same.
Now, if I ever did run into an interview where they wanted me to write code on a whiteboard, I’d probably pseudo code it out and explain that I’m a huge fan of Intellisense, particularly ReSharper, and Google and that I rely heavily on those two to get the syntax right.
If you want a guy who can write code in notepad, I’m probably not the guy you’re looking for. If you want a guy who can solve problems, who understands how to write testable code, write unit test, can mentor younger programmers, understands what it really means to be agile, and can say “no” to power when it is appropriate, then I’m the guy you want.
Continue reading “Cracking the Programmer’s Interview Code”
As you advance in your career, you will inevitably want to improve as a programmer. And as you search the Internet and read various web post on the subject you will also inevitably end up with a bunch of task you should perform that will make you better.
For example, if you’ve been following this blog lately, you’ll notice that I’m a big proponent of Test Driven Development. You would naturally expect me to state that to be a better programmer, you should practice Test Driven Development.
There has also been a lot of emphasis recently on good basic programming principles like DRY and SOLID.
The list could go on. Here are a few you may be interested in experimenting with:
- Code Reviews
- Paired Programming
- Learn and Implement Design Patterns
- Reduce Method/Class Complexity
- Practice Code Katas
- Participate in the Community
- Start a Blog
- Participate on StackOverflow
- Read and Comment on other people’s Blogs
And while all of these and more are good ideas, none of these ideas will actually MAKE you a better programmer. Why? Because becoming a better programmer is mostly about becoming a better person.
Continue reading “How to Become a Better Programmer”
At the risk of making half of my audience think I’ve gone off the deep end, I’m going to address a topic that I’ve only recently REALLY begun to understand, in part thanks to Soft Skills.
When I’ve heard the topic of “Limiting Beliefs” come up, it has almost always been in the context of something along the lines of “What the mind can conceive and believe, it can achieve.” Which is easy to disprove. At least it is out of context! I mean really, if I can conceive and believe myself to be a butterfly, it just isn’t going to happen!
However, the opposite is pretty easy to both accept and believe. And that’s what I want to talk about today. But even then, it probably isn’t what you are expecting.
Typically, when people talk about Limiting Beliefs, they are talking about patterns and practices you picked up as a kid that are holding you back now. And while those may be areas that you need to work on, what I want to talk about today is more micro than that, although they may have roots in our past for various reasons, the Limiting Beliefs I want to talk about today are common across nearly every programmer I talk to.
Continue reading “Limiting Beliefs of Programmers”
A while ago I wrote an article explaining what SpecFlow is, and why you might want to use it. I’ve been using it for several months now and I’ve recognized several patterns that have emerged in my usage that I wish I had known when I started, so I thought I’d share them with you today.
Continue reading “SpecFlow Strategy”