Go away. It will all be waiting for you when you return.

I realize that my posts here have become a bit infrequent and erratic. If you’re a frequent reader, you know that I changed jobs early this year. I didn’t just change jobs though; I completely swapped stacks. Learning a dozen technologies “overnight” has taken up a lot of the time that I previously dedicated to writing. I also had my first ever speaking engagement in May, just as my wife was finishing up her degree. Needless to say, we’ve been having a very busy year to date. I’ve simply not had the time or mental bandwidth to regularly update this blog. I tried, but I don’t feel like it’s been my best writing. 

When I first started writing this blog, I had set myself a goal of one new post a month. That made a ton of sense at the time, but I never revisited that goal to make sure it still made sense. Even with everything else going on in my life, I (quite unintentionally) put pressure on myself to meet that goal. At some point this Spring I realized I couldn’t do it all and let some things slide. 

It’s important to know where your limits are. There are only so many hours in a day. We must wisely choose what to do with them.  I severely underestimated how much time it would take to prepare a presentation, which is funny, because it was largely about not doing “gut” estimations. I sacrificed time with my family and time writing here in order to share something I felt was important to share. Since then, I’ve been focused on making up for the lost time. In fact, we just got back from a fantastic camping trip. 

Burn out is a common theme in software development. For all our talk about creating software at a sustainable pace, many of us are not moving at one. It’s not always our stakeholders and clients pushing us past our limits either. They’re an easy scapegoat, but in many cases, it’s us pushing ourselves past our limits. We’ll go in early, stay late, or log in from home to check on a long running process. We don’t say “no” often enough to though “aggressive” (cough impossible cough) deadlines. That’s our own fault. We’re responsible for our own health and well being. We’re responsible for creating a sustainable pace of development. 

How long has it been since you’ve taken a vacation? I mean a real vacation, not a day here or there, or a week where you check your email and Slack five times a day, but one where you leave the laptop at home and shut off your phone for a week. How long has it been? My last one was at least seven years ago. Granted, I may be a workaholic, but that’s about six years too long without a break from it all. Creating software is a massively creative endeavor. How did I expect myself to remain creative without taking time to recharge those creative juices?! I don’t know. I’m some sort of idiot I guess, because I feel better than I have in years. I feel ready to solve problems and inspired to write again. 

If it’s been a while since you’ve unplugged, I highly encourage you to do so. Take a few days and pretend it’s 1995. Navigate with a paper map to someplace new and exciting. Go hiking or visit a museum. Spend some extra time with your kids. Whatever recharges you, go do it. You won’t regret it. 

~ Semper Cogitet
P.S. This was supposed to be an update about what’s coming up in the next few months, but I seemed to have found something more important to say in the process of writing this post. I do have a few technical posts on my todo list and at some point I intend on turning my Lean Estimates talk into a blog post. They’re coming, but not a huge priority for me at the moment. I’ll write them as time allows, however I have prioritized time with my family and some house hold chores over this blog. I expect to post one new blog about every 6-8 weeks instead of every 4-6. So hang tight while I find a sustainable pace for this blog. 

Do you want to be a VBA Developer, or do you want to be a Software Developer?

I’ve seen a number blog posts by very good VBA devs worrying about the future of the platform and their careers. They’re right to be concerned, but not because they’re VBA devs. A Java developer should be concerned. A C developer should be concerned. And yes, a C# developer should be concerned too. 

You see, these folks are worried that their platform/language of choice is going to become obsolete. If it’s the only one you know, that makes you obsolete too. If you’re an X developer, then any given day could be your last. As new technologies become prevelant, old ones become more and more niche. The jobs fade away with the old stacks. If you want to protect yourself and your family, then you need to have more than one hammer in your toolbox. I think you have to ask yourself, do you really want to be a VBA developer or do you want to have the security of being a Software Developer?

It’s often said that bad developers can write bad code in any language, but the opposite is true too. Good developers can write good code in any language.

I’ve had a few folks ask me how I made the jump from being a VBA dev to being a C# dev.  The truth is, I wasn’t ever a VBA dev. My first (and second) language was BASIC. Then I learned some Java. At this point, it was only a hobby. I had no dreams or aspirations of doing this professionally. I was a Planogram Analyst. My job was to create schematics to show people where to put the right amount of the right product on the shelf. It was a tedious job, so I started using VBA and JDA Space Automation (a proprietary scripting language) to automate my work. I bet many of you VBA developers out there started the same way. 

Being a nice guy, I shared these tools with my coworkers. Eventually, I was asked to do it full time. That’s when I had to learn some SQL. Soon after, I started using SSIS for all the ETL jobs we needed. So you see, I was never really a VBA dev. I was a software developer. I learned and used whatever tool I needed in order to get the job done. 

Still, if you looked at my resume At the time, you would have labeled me a VBA dev. Perhaps, a person could be justified in doing so. Hell, 6 months ago, you could have easily labeled me a C# dev, but I’m not. I’m more than that and I bet you are too.  It’s often said that bad developers can write bad code in any language, but the opposite is true too. Good developers can write good code in any language.

That doesn’t matter much to recruiters and hiring managers though, does it? So how did I make the jump away from VBA professionally?

First, I accepted that being labeled a VBA dev was putting my future at risk. Then I picked a language that was in demand and started learning it. I’d write solutions to Project Euler problems and post them on Code Review Stack Exchange. There, I could get feedback from professionals who really knew the language. That feedback is absolutely critical to really learn something. Without it, you don’t even know that you’re making mistakes. 

Next, I started getting serious about OOP, SOLID, clean code, and unit testing. I’d spend my time reading books like Clean Code and Code Complete. I started to ruthlessly apply good engineering practices to my VBA code at work. Only, VBA didn’t quite have the toolset I needed to really test drive my code. So, I started building them, in VBA at first, but soon after the Rubberduck project was born. Finally, I ended up breezing my way through an paid and verified EdX course for some “formal proof” that I knew the language I’d be using at the places I was applying to. 

Now I had all the ammo I needed to make the jump, but it still wasn’t easy. I had to treat finding a job like it was a job, because it was. During the time I was looking for work, I was spending at least 20 hours a week writing cover letters and performing phone screens, on top of my 50 hour a week job. I nearly burnt out before I finally found a great place to work, but I did find one and made the jump. Since then, I’ve started to learn C, C++, and embedded development. 

So, for those of you who’ve asked me how I made the jump from VBA to C#, I’m still not sure that I’m the right person to ask, but here’s my TL;DR:

1. Learn how to write Object Oriented VBA. 
2. Stop thinking of yourself as a VBA dev. 
3. Learn an in demand language. 
4. Learn how write good unit tests. 
5. Start contributing to an Open Source project written in your new language.
6. Get a certification, even if it feels silly. 
7. Make it your job to find a new one. 
8. Never stop learning. 

IT as Couples Counseling

Do you ever feel like a teenager passing messages between your separated parents?

Joe in receiving puts in a ticket asking you to look into an issue. You take a look at it and realize that it’s because Barb in purchasing failed to check a box. So, you email Barb and ask her to correct it. Barb corrects it and you go back to Joe to see if his issue has been resolved.

Joe says, “Yup. Looks good now. Thanks. This is the 3rd time this week those idiots over in purchasing screwed up.”

“What do you mean this was the third time this week?”, you say.

“Well, I got tired of complaining about it, so it was easier to just put a ticket in. Those asshats know the process, they just don’t do it and it causes us to get behind. I don’t have time to go hunt them down every time they screw the pooch.” Joe laments.

You want to reply, “So you wasted my time on an issue you could have fixed yourself?!”, but instead you just sigh and walk back to your desk, dejected. There was no reason for IT to even be involved in this. Joe could have just called Barb, politely asked for her to fix it, and moved on with his day. He didn’t because he’s angry at them and it was easier to have IT address it. Why not? IT fixes all the problems, don’t they?

We could easily just continue to just deal with the problem as it interrupts us, but that doesn’t address the issue at all. It’s just putting our heads in the sand and saying “Not my job.” If we want to stop playing messenger, then we’re the ones who need to take action. Once a feud between two departments in an organization begins, it’s extremely unlikely that it’s going to end without outside intervention. Like it or not, IT is a neutral party that both sides of the problem trust and it’s up to us to fix it.

That’s not real experience

I recently had a pretty big change in my life. My company went through an internal reorganization. I was left with a choice of moving my family a few hundred miles or finding new work. Since the prior wasn’t really an option for us, I took the opportunity to make a career move. 

Now was as good a time as any. Luckily, I didn’t have too much trouble finding a replacement job, but finding it was quite an experience. It turns out that nobody is interested in hiring a VB6 developer these days, and if they are, they want to make your job title “Excel Analyst” and severely underpay you. Seriously people, a good VBA dev is worth their weight in gold compared to all the people writing spaghetti with the macro recorder. Find a real programmer and pay them what they’re worth. You may spend more now, but it will save you tremendously in maintenance costs. But I digress…

VB6 was replaced by .Net twelve years ago, so I was looking to move on from VBA development and (professionally) into .Net development anyway. Getting my foot in the door without any professional .Net experience turned out to be quite a task though. I can’t tell you how many times I heard a recruiter or HR screener say, “But where is your .Net experience. All I see is this open source project. Don’t you have any real experience?” Even now, months later, that statement makes my blood boil. Let me tell you folks, experience writing open source software is real experience. The last time I checked, Rubberduck was at over 35,000 lines of code excluding the ANTLR generated code. It’s as large and complex as any CRUD app I’ve created in 5 years of professional software development, if not more so. Open source development teaches you more than just code though. It teaches you a number of other things as well. 

The Professional VBA Developer

I came across a post on Programmer’s Stack Exchange yesterday that really irked me. It took me a little while to really digest what upset me about it, but I think I understand now. This developer was asking for more reasons to back up his claim that he should move his solution from VBA to C#. That in itself is fine. As I stated in my response, I understand his desire to move his solution to C#. I wish I could move all of my projects to the .Net platform myself.

No. Wanting to move to a more modern technology was not my issue with his question. My problem was with how he acted like working in an old technology gave him a pass on being a professional.

More Popular than Ever? Beards and Masculinity in History.

I found a fantastic (yet brief and incomplete) history of the beard. I’m a believer that the modern man should rock a well trimmed beard. It’s both stylish and manly. Oddly enough, or perhaps not so oddly, current trends in facial hair are having economic impacts. I hope you enjoy this as much as I did.

This week came the startling revelation that, in the past year, manufacturers of razors and related goods such as shaving foam, have seen a drop in sales of more than £72 million pounds. Market analysts IRI noted that men’s shopping habits were changing

http://dralun.wordpress.com/2014/09/22/more-popular-than-ever-beards-and-masculinity-in-history/

Jitters, they’re not what you expect.

To those of you who read my drivel for the software stuff, I apologize. There will be no mention of code this week, other than that one. You see, I’m getting married to the funniest person I know two weeks from now. Needless to say, I have more important things on my mind.

My beautiful wife to be is giving me the best present a schmuck like me could get, two daughters. So, I’ve got the jitters, but they’ve nothing to do with getting married. My fiancé is my soulmate and there is no doubt in my mind when it comes to making her my wife. What has me nervous is the solitary question of, “Am I good (Step-)Dad?” I know; it’s cliché. Every parent wonders if they’re doing a good job of raising their kids, but that doesn’t make the question any easier to deal with.

The only Dad I ever knew was the man who married my mother and raised me as his own. Let me make this clear, he was not what I would call a good man, but he was an excellent Dad, while he was still around. Furthermore, he didn’t have to raise me as his own. He could have treated me like what I was, someone’s else’s child. He didn’t though, and that is his one true redeeming quality. He stepped up and did what should be done, instead of just doing what he had to do.

My girls are lucky enough to have their Dads in their lives, but that doesn’t mean that I don’t take my job very seriously. I treat them like my own because it’s what they deserve. Anything less just wouldn’t be right. I guess that’s what I’m here to say today. I’m here to challenge every man out there to do what’s right, to go above and beyond the call of duty, and to remember that your wife’s kids are your kids too, even if they aren’t.

They’re not always going to like you or listen to you, but you better damned well be there for them when they need you. I’m sure I’ll mess up along the way, but every parent does. After all, we’re all only human. If my Dad taught me anything though, it’s that being there is what matters most when it comes to children. That much I can do, so there’s nothing to fear. Some kids are lucky enough to have a father in their lives, mine are lucky enough to have two.

In the Zen Zone

I was reading a blog the other day about Zen Coding and it really just bummed me out. Zen Coding is a very real thing. You all know what I’m talking about, even if you don’t realize it. It’s when you’re just in it, completely in it. It’s when you don’t exist anymore, you’re in the zone and there’s just the code, nothing else. There’s just the code and you make the computer dance. You bend it to your whim and will. It’s the most beautiful thing that can happen to a programmer… and I have not had that experience in a very long time now.

What’s worse than not being able to experience the bliss of letting myself go, of losing myself in the meaningless lines of text in front of me that I give meaning to, is not understanding why I can’t find that place. It’s utterly frustrating. If I did not know this state of mind, this Zen Coding, I would not care. However I do know it and this knowledge is a burden, but rather than whine and bemoan my sad state of affairs, I would prefer to explore why this state of zen has eluded me. Perhaps more so, I want to explore how I can attain it more often.

The biggest road block to finding the zazen of programming is distraction. When the phone rings or someone comes into your office, you have just been kicked out of the zone. It will take you longer to figure out where you were than it will take to deal with the interruption. These kinds of distractions can not be stopped and they are hands down my worst nightmare. It’s never just one either. These distractions come in packs. One phone call takes you away to deal with an emergency, then just as you’re finishing up that one, the phone will ring again. To medigate the damage from this you must finish your current thought. Whatever it is, it can wait 30-60 seconds for you to wrap up your immediate thought. You’ll thank yourself later for having one less “what the fuck?” to cope with when trying to get back to what you were working on six hours ago.

Interruptions aren’t the only distraction though, oh no. Email is a huge culprit too. If you can, only check your mail a few times a day. Don’t jump to every little thing. They emailed you. They don’t expect an immediate response, so don’t give them one at the sacrifice of your concentration and focus. While you’re at it, turn off those “oh so helpful” desktop notifications. They catch your eye and take your mind away from the task at hand. The longer you spend consecutively focused on your task, the easier it will be to slip into Zen Coding.

What is the real problem though? Why is it so hard to just get in the zone? I have one word for you, stress. Fear is the mind killer and stress is its asshole cousin. In order to be productive, stress must be removed from the equation. Stress will scatter your mind like dandelion seeds in the wind. Do whatever you have to do to reduce and eliminate stress from your workday. Five minutes doing push-ups, or simply walking away from your desk, will buy you twice that time back. I promise.

There’s one more trap that I know I fall into far too often. I’m not enjoying myself. In order to be productive and happy, you must be enjoying yourself. There is no other way to be one with you code, but to want to be. Sometimes this means putting off a new feature and fixing that crap you wrote six months ago. You know the code I’m talking about. You wrote it in a hurry, or just didn’t really know what you were doing yet. It sits in your code base like a giant stinking turd taunting you every chance it gets. There’s never time to fix it, so it stays there just festering and driving you crazy. I’m telling you, take the time to polish that turd into something you’re proud of. The next thing you know, you’ll have refactored half of your code base because cleaning up that one method or class slipped you into zen mode. You’ve gotten your mojo back and each new change and feature will be that much easier to implement. You owe it to yourself. It will be cathartic. Just do it. Trust me on this one.

I’ve been slacking…

about writing here at least. In reality, it’s been a really busy summer. In between work, trips to the zoo, horse riding camps, volunteering some time at Code Review SE and (oh, yeah) getting ready for our wedding, I’ve not had much time to think about this blog. Which is okay, but I did promise myself I would write something at least once a month.

It’s important to me that I keep that promise to myself. Most Programmers think that their most important skill is the ability to write clear and concise code. I would challenge that. We should generalize that and work on being able to write clearly and concisely whether we’re writing in C#, VB, or English. If we can’t communicate with the business, we will not be effective programmers. If we can’t communicate with each other, we will not be effective programmers. If we can’t communicate with the non-programmers in our lives, we will not be effective human beings.

I know I’ve been absent for a while, but I kept my promise. I’ve accomplished a goal and I feel better for it.

Until next time, Semper Cogitet.

The Last Mile – Why Good Enough Isn’t

A few weeks ago I was talking to a particularly good friend of mine. We somehow got on the topic of “good enough” and how it just isn’t. Let me preface this with “I’m guilty”, and I truly am. There’s no way for me to say this without sounding condescending, so please believe me that I don’t mean it to be arrogant. My “good enough” tends to be better than average. This has allowed me to more or less skate through life and let me tell you something, I have not done nearly enough.

Oh sure. I’ve done pretty well. I have a good career, a great family, and the best friends a guy could ask for, but what have I done? The truth is I’ve done a lot, but not nearly as much as I could. Why is this? Because I, like you, am lazy. Of course I’m lazy. I didn’t intentionally become a programmer. I became one because I was lazy. I understood that if I put the effort in up front to build a piece of software to do it for me, I would never have to waste another second doing it by hand again. That’s also the only reason my good enough is better than average. I’m lazy, but I recognize that it’s a better investment to do some extra work up front in order to reduce the overall amount of effort over time.