Scene: It’s midnight. We slowly pan over a sparsely filled library. We zoom in on a tense, frazzled Computer Science student. With a practiced hand, he fills his code with print statements and debugs his code for umpteenth time. He steps over and over lines of code, struggling to find the reason why his code silently fails.
He could write some tests, but what’s the point? They’re bound to be as flawed as his understanding of his code, right? Besides, it would take time he doesn’t have to write all those tests. Left to his devices, he struggles for another hour or so before realizing he had an off-by-one error on one of his giant “for” loops.
I’m sure I’m not the only one who’s been in this situation. Rather than deal with the extra work of writing tests, you just decide to wing it. It could save you time, but on the other hand, it could cost you some painful nights of debugging some unfortunately timed bugs. So what exactly are the pros and cons to testing your code? Continue reading “Testing Your Patience: The Pros and Cons of Test Driven Development”
Development is filled with questions. What’s the best approach? What should I name my new object or class? Where is the best source for information? Depending on who you ask, you might end up with some opinionated answers; a few may even verge on fanatical. “C# is the best programming language, hands down.” “Only languages with managed runtimes are worth coding in.” “If we just had X, it would solve all our problems.” Unfortunately, answers usually aren’t so unconditional.
“Life isn’t black and white. It’s a million gray areas, don’t you find?”
― Ridley Scott
Continue reading “The Default Developer Answer: It Depends”
We’ve all written our fair share of code. Sometimes it’s elegant and well-reasoned, and sometimes it’s convoluted and flawed. No one is perfect. There will always be that moment where you look at code you wrote a year, a month, a day ago and say “What was I thinking?”
So it stands to reason when someone else is reviewing your code, or just happens to stumble upon it one day, they could have the same thought. Maybe they have a different solution in mind. Maybe they see a bug you missed. Maybe they just don’t like the way it reads. For one of a million reasons, they could decide your code is lacking in some way. And, in all likelihood, it is.
Continue reading “Developing Yourself: Sometimes Code Is Just Code”
I know this is a little late, but since we just experienced a leap year I thought now would be a good time to cover my top 4 tips for working with dates and times. Most of these tips come from painful lessons, some of which I learned the hard way, some of which I was fortunate enough to learn second-hand.
Continue reading “Date and Time Management: 4 Tips for Preventing the Future From Catching Up With You”
There are plenty of amazing developers out there. They turn software development into an art form, designing elegant programmatic masterpieces in a fraction of the time.
Then there’s me.
Don’t get me wrong. I can whip up a new application, design a new web page, or test drive some new functionality in. It might take some time and/or googling, but I can definitely do it, and I’m sure most developers can say the same thing. Those technical skills develop (there goes my allotted pun for the post) with experience and time, hopefully into something at least approaching the level of talent I mentioned before.
But what about all the other skills? Continue reading “Developing Yourself: You Are More Than Just Your Code”