Dirk Strauss

Trust but Verify

This was the almost signature phrase adopted by Ronald Reagan.  At the signing of the INF Treaty he used it again and his counterpart Mikhail Gorbachev responded: “You repeat that at every meeting,” to which Reagan answered “I like it.” Well in my mind, Ronald (who by the way, would have been 100 years old on the 6th of February 2011) had a point going there. How can we as developers adopt that mantra to our work?

A couple of months ago, I worked on an Interface that communicated XML files between two disparate systems. The developers on the other side assured us of the file layout that they could receive. Turns out that if a Tag was not in the right place, their system would ignore the file and just “lose” it. With that, I mean the file would be thrown into the cyberspace equivalent of a black hole from which no binary bit can ever escape. Luckily we decided to audit the actual XML sent to them, which allowed us to resend the file if needed.

This requirement was not actually in the spec, but then again, the other “team” didn’t stick with what the specification stipulated anyway. There is a saying “Walking on water and sticking with a specification is easy if both are frozen”. Well, I can tell you, those folks kept on changing it to suit them. What this all boils down to in the end, is don’t ever assume. Like Bruce Willis said in one of his movies…. “Assumption is the mother of all…… ahem….. mistakes”.

A good rule of thumb (well for me anyway) is to develop for the worst case scenario. I always ask myself “What if…”. What if the system we are sending this file to loses it. What if only one of the two database transactions succeed? What if the end user does this or that. Is the application user friendly? How easy will what I am coding here be to maintain if another developer had to maintain it? I know that some companies enforce certain standards, but I believe that as a developer, you need to have a few of your own. If you see an area of the development process that might be risky, take it upon yourself to moderate that risk. You will reap the rewards in the long run.

Reference Flickr

Streams of Inspiration

When do you know it all? You might be wondering what I mean by saying that, but is it possible to ever say that you know all there is to know about your chosen programming language? There are really some very good programmers out there. Guys and girls that dedicate their lives in the pursuit to knowing all there is to know about their language of choice. And when you come across one of these individuals, their grasp on that specific technology or topic is astounding. How do they do it, you wonder? They must know everything about XYZ.

Well, I can tell you now that due to the nature of technology, knowing everything is damn near impossible. But knowing a lot, isn’t. I think that to be one of those programmer superstars, you need to be a 24/7 programmer. Basically, you get two types of programmers. You get a 9 to 5 programmer, that only focuses on writing code during work hours. But come 5pm, they will have nothing more to do with anything IT related. These are the people that develop software just in order to collect a paycheck at the end of a month. There is little or no pride in their work. They aren’t team players, and they can pull you under if you’re not careful.

The 24/7 programmer

Enter the 24/7 programmers. No, I don’t mean somebody that sits in front of their PC 24 hours a day, 7 days a week writing code. That’s just stupid. And if you are currently doing that, you either have a deadline to meet, or you have a problem. Get help, because you need time to relax too. What I mean by a 24/7 programmer is somebody that still has their programmer hat on when they leave the office. They might not be writing code after 5, but they still surround themselves with IT related streams of inspiration. They are a rare breed indeed.

To do this they are the type of person that subscribes to professional magazines relating to their topic of interest. They subscribe to blogs. They follow professional people on Twitter. They sign up to sites like Stack Overflow or Code Project. They are the type of person that sees each and every programmer they meet, irrespective of field of expertise, as an opportunity to learn something new.

Twitter

While I am on the topic of Twitter (and because I am totally addicted to it), let me interrupt myself quickly. If you are a programmer, and don’t have a Twitter account, then get one now. Sign up using your real name if available and follow people that share the same interests as you. Trust me, Twitter has a wealth of knowledge and you can really learn so much by what other people post. Oh, by the way, you can follow me here http://twitter.com/DirkStrauss

Since I started using Twitter, I have learned so much and made so many new friends. Obviously I started off following a few celebrities, but I have scaled that down a bit. As a programmer, here are some of the real gems I follow on Twitter: @patelchiragca (Chirag Patel), @abhi2434 (Abhishek Sur), @beckynagel (Becky Nagel), because I find maths fascinating @mathematicsprof (math prof), @CreativeAddict (Lisa Casson), @tonylukasavage (Tony Lukasavage), @sharpcms (Jürgen Gutsch), @dougholland (Doug Holland), @priyanr (Priyan R), @mbcrump (Michael Crump [MCPD]), @jonskeet (Jon Skeet), @joefeser (Joe Feser), @Tordf (Tord Fauskanger), @olgachaidou (Olga Chaidou), @siravington (Steven Moseley), @adatapost (KV), @amazedsaint (Anoop Madhusudanan), @jcdickinson (Jonathan C Dickinson), @scottgu (Scott Guthrie), @AddoLover (Vincent van Zyl), @JanesOosthuizen (Janes Oosthuizen), @jfayling (Jason R. Fayling), @HilzFuld (Hillel Fuld), @AkiAnastasiou (Aki Anastasiou), @RABotha (Reinhardt A Botha), @shanselman (Scott Hanselman), @DennisCode (Den Delimarsky), @Elsheimy (Mohammad Elsheimy), @ProgrammerWorld (Programmer World).

Conclusion

The idea behind creating true wealth is generating many revenue streams. The same can be said of becoming a better programmer. Create many inspirational streams. Use Social Media to your advantage and as a tool to learn something new. If you want to grow your expertise, don’t confine yourself to one technology only. Learn as much about as much as you can. There is Always something new to learn. Just because it might not be the latest thing, it might still be new to you.

Reference: Flickr

Hello C# My Old Friend

Simon & Garfunkel’s song title (Hello Darkness my old friend) reminds me of how I feel we should see the language we develop applications in. It should be a friend, not true? In other words, you should be very comfortable with your abilities developing in your language of choice. I’m a C# developer, and I love the language. I try to expand my understanding of it continually. In fact, you should never think that you know it all. Most importantly, you have to remember, that your pride must be left at the office door before starting your work day. There will always be another developer that knows more about a specific topic than you do. And you need to be big enough to take advice when given. But I don’t specifically want to talk about this.

As a programmer, how do you color your professional life? Do you confine it to a single language? If you had to list your programming languages on your CV, how long would that list be? Are you a one language programmer? I guess in some cases it isn’t bad, but imagine if you could list 3 or 4. As a .NET developer, I can write an application in C#, VB.NET and Java (although I haven’t done Java in a while). But imagine expanding that list. A friend of mine recently challenged me to learn PHP, and this ties in nicely with my one new years resolution to learn a new language this year.

You see, as programmers we might get frustrated with learning a new language especially since you can do it much faster in the language you know. For me, anyway, that has been the frustration. C# is my old friend to whom I turn to when I need to code. But I feel that sometimes we need to break the habit a bit. Remember, it’s always just syntax. The logic remains the same (A loop is a loop). So when learning a new language, you just need to get used to the syntax.

Certain African Tribes had specific places of worship away from their village or hut. A regular commute to worship their gods would wear out a path in the grasslands of the Savannah. If the village elders saw the specific path being overgrown with weeds and grass, they would know that some of the villagers were not going to worship as regularly. They would then be reprimanded. It is the same with learning new things. The more we do it, the more defined our understanding of it becomes (The grass path analogy). We need to do in order to understand it.

For me, my first love will remain C#. But I know that I am at heart, a programmer and being a programmer shouldn’t mean to be confined to only 1 language. So, my challenge to myself this year is to learn PHP and Objective-C. How about you? What is your challenge to yourself this year?

Reference: Flickr

Working from Home – The Pros and Cons

I have taken some time to write this next post, simply because I wanted to give it some thought. Working from home….. It sounds like a dream come true, right?

My company has their HQ in Johannesburg, and I have been working for one of their provincial branches from my home for the past 2 and a half years. The other day I was stunned that it had been so long. I then started thinking about the road I had traveled and how I have become accustomed to working alone.

First of all, some of the plus points are that I have so much more time with my family. I can also spend some quality time with my baby daughter during lunch hours. There is no morning commute through traffic to get to the office. The only commute that I am used to is down the hall to my office while grabbing a cup of coffee along the way. This commute also doesn’t cost me anything on fuel. But working from home does have a few proviso’s. There are a few things that are essential to any telecommuter.

Your Office

You have to have one. This is the most essential part of working from home. Your office, for all intense purposes, must be an extension of your on site office in the city. You must have all the tools you would normally have at your company. But you must also have some extra tools at your disposal too.

• A fast connection to the Internet
• Fax machine, scanner, printer
• Preferably a Laptop
• A backup connection to the Internet such as a 3G dongle
• Some external Hard Drives (I’m already at 1.5 Tb)

While your office should be comfortable, it should also be functional. Make everybody understand that when you close your office door, you are at work. Interruptions should be kept to a minimum. I would recommend utilizing a separate room in your house as your office. If you have a study, great, if not, you’ll have to use up one of the other rooms. Never think that you can do your work from the kitchen table or from bed and still be productive. Lastly, when the end of the day rolls around, and it is time for you to “go home”, closing your office door separates your work space from your relaxation space. Never mix the two. This allows you to switch off after work.

Connect with Colleagues

When you work from home, you can’t pop round to your colleague’s cubicle and have a quick chat. There are no more water cooler conversations or Friday Afternoon beers. When the office goes out for lunch (something that our office does once in a while) you will not be with them. You will, and this might sound harsh, be totally alone. If you can’t handle the solitude, then working from home might not be for you. I find that I am much more productive when I work from home.

Every once in a while I fly down or drive the 700km’s to my office and work there for a week or so. While it is absolutely great seeing my colleagues and friends again, I do find that my productivity does take a knock. Simply because of the interruptions (office door bell, telephones ringing, keyboards clicking as people type, colleagues talking to each other etc.). While there is much to be said for working in an office environment, it has it’s drawbacks, just as working from home does. One big drawback with working from home is that you have to fend for yourself. If you have a problem with whatever, you need to rely on Skype, the telephone or a similar solution to communicate with your support base. While this does teach you to solve more issues on your own, face to face communication is alway nice.

Get Out

If you aren’t careful, you could end up spending a couple of days in the house without stepping outside once. This isn’t healthy for anybody. The Internet provides us with so much to do and so many communication channels, but nothing (not even Google Street View) can compete with the feeling of grass beneath your feet. What I mean to say is that you have to take a break. Remember, working from home makes it so easy for you to work longer hours than you would normally do. Simply because you don’t have to drive home. Also, try never to skip your lunch hour. In fact, take a nap during your lunch. After all, your bedroom is just down the hall. Studies have shown that people that take an hour nap at lunchtime are productive at a higher level after their nap, than at the peak of their productivity before their nap. Why? Well, simply because your brain does get tired, and taking a nap, gives it time to rest and “flush” out the memory banks.

Invest in your equipment

What do I mean by this? Well, don’t buy a cheap office phone. Get one that is nice and comfortable to use. Don’t settle for the plain budget beater fax machine or scanner. Don’t buy a bottom of the range router. Invest in proper equipment. Part of my job requires me to access and use various Virtual Machines in order to simulate various live environments for testing purposes. And as any of you know that have used VM’s before, they can get quite large. So instead of having the lag of accessing them over my VPN connection, I simply store local copies on my external hard drives.

I also keep copies of my source code and other customer related documentation and files on my external drives. And while I have a second drive as a backup for my primary one, I also use SharePoint across the VPN to store my documentation. You need to be set up in such a way that you can work seamlessly when not connected to your corporate network due to a network problem. I had no Internet connectivity for a whole week earlier this year, due to the national telecoms operator (Telkom) struggling to change a port in the local exchange that was not working due to lightning damage. Well, it left me high and dry and I had to rely on my 3G dongle for connectivity.

Lastly

Remember, even if your employer can’t see you while at the office, never take advantage of this and slack off. Your employer has put much faith in you by allowing you to work from home, and betraying that trust is counterproductive and will play havoc with your karma.

Reference: Flickr

If you understand it, you can code it

In the 1989 movie, Field of Dreams starring Kevin Costner, his character (Ray) hears a voice whisper, “If you build it, he will come”. He sees a vision and promptly proceeds to turn his corn field into a baseball field. Well that takes a bit of determination and a lot of know-how. Ray knew how to grow corn (and believe me, farming is very, very hard work) but building baseball fields is a whole different story. What I am trying to say is the following; If you understand what you need to do, you will be able to do it. I am convinced that programmers should live by this mantra.

Often there is a total communication breakdown between the analyst and the programmer. That is because the analyst that wrote the functional requirements for the system speaks analyst. Most programmers speak geek. Don’t believe me? “So I need to create a class of type Sales Order that will enumerate the collection of order lines and execute a non-query to the database to insert the record for the linked Sales Order Header ID?” Sitting across the person that made this statement is a very nervous, wide-eyed analyst. Okay, so perhaps this isn’t the best of examples, but you get the idea.

Sometimes I see programmers (especially junior programmers) that sit in a meeting where the requirements are being discussed, and I can see that this guy or girl have no cooking clue what everything means. This reminds me of the time that I had an 8 am appointment at a client in Johannesburg. Traffic is always a nightmare and I made sure that I had read through the requirements documentation my manager had given me the day before. Needless to say, the GPS took me on the wrong route and I ended up being late for the meeting. When I arrived, the meeting had just started and I was the last to sit down. These guys then started discussing the requirements for the proposed system, and I soon realized that what I had read the night before, was absolutely and utterly a totally different system. My manager forgot to give me the second requirements documentation for the second system they needed.

I decided to bunker down and listen VERY intently to what was being discussed, in the hopes of catching the gist of it all. Then, the horror of all horrors happened. My manager turned around and asked me for my opinion. I broke out in a cold sweat, I could feel the whole boardroom looking at me in expectant anticipation. I was, for the very first time in my life, totally and utterly at a loss for words. I mumbled something about them having covered all the bases, and that the proposed solution sounded solid and luckily the finance guy interrupted with a question to one of the other attendees. (I at least redeemed myself when they started discussing the system I had read the requirements documentation of.)

But so many times, I see programmers with that look on their faces… the one I had on my face in that meeting. What I can’t understand is that this behavior is so prevalent in junior programmers. Even if you ask them if they understand what is needed or what was discussed, they often say ‘Yes’. So the ninth tip I would like to share is that, if you understand it, you can code it. End of story. We as programmers should be comfortable with our programming skills. In fact, I almost would like to say that what we understand from the requirements of a new system should translate directly to code within our minds. We should be able to conceptualize the application before we write a single line of code.

So never be afraid to ask questions. If you don’t understand, ask. You are after all translating business jargon into C# or Java or whatever language you code in. If the roles were reversed (in other words, you talking C# and an analyst needed to draw up a FRS from that) I will guarantee you that the analyst would have a couple of questions for you. In fact, what we as programmers often need to do it quite difficult. So make sure that you understand completely what is required of you. You will see, once you know that, the code will come naturally.

Reference: Flickr

Stay up to date

I used to know this guy who always said “Be prepared is a boy scout marching song“. Well, in order to be prepared, you first need to be up to date. In 1978 Porsche released this advert for the 911. What an awesome machine…. in 1978. The truth be told, it is still an awesome car, but the fact is, there is a better, faster more luxurious 911 in the market right now. The same is true about your skills as a programmer. While you might be hot stuff today, by next month you might be… well, a bit outdated. We as a human race live in exponential times. So as a programmer, you have to adapt to the changing way of the industry we work in.

I would like to say that if you as a programmer never buy books on programming in your specific field of expertise, you are on your way to an abrupt end. For example, when Visual Studio 2010 was released and the .NET Framework 4 announced, did you make an effort to read up about the new features available to you in the .NET Framework 4? Okay, let me step back a bit. Do you know what Generics (C# v 2.0) are? Have you worked with LINQ (C# v 3.0)? Do you know that you can now use Optional Parameters in C# 4.0?

Well, I really hope for your sake that you are going “Yeah Dirk, tell me something new”. If not, you should have alarm bells going off all around you right now. Do you still remember where you were in 1998? That was the year I got my first Tattoo. It was also the year that:

• Paula Jones accused the then U.S. President Bill Clinton of sexual harassment.
• The Unabomber (Theodore Kaczynski) went to jail forever.
• Google, Inc. is founded in Menlo Park, California, by Stanford University Ph.D. candidates Larry Page and Sergey Brin.
• Sky Digital Satellite Television launches in the UK.
• Microsoft releases Windows 98 (First Edition).
• The Galaxy IV communications satellite fails, leaving 80–90% of the world’s pagers without service.
• The first XML specification is released.
• The movies Armageddon, Saving Private Ryan, Deep Impact and Lethal Weapon 4 were hits.

Oh, it also happened to be the year that VB6 was released. While I know that many developers evolved as VB did, with most of them calling Visual Basic .NET their language of choice, I know of other developers who only know VB6. Well, if you are one of them, you better make a plan. I started with Visual Basic.NET on the framework 1.1. These days I do more C# programming than anything else, but I had to evolve. You can take this even further if you like. If you are a .NET developer, do you only know .NET? How about learning a bit of Objective-C or Java.

You need to continually make yourself marketable by forcing yourself out of your comfort zone and learning new skills or languages. You must realize that you need to avoid becoming a byproduct of the fast paced industry we work in. At all costs, avoid becoming obsolete. Keep up to date with the latest trends. If you don’t know how, subscribe to programming blogs, join Twitter and follow programmers, buy a new programming book and learn from it. If you leave it till it is too late, you will be left out making it will be nearly impossible for you to catch up with the rest of the industry.

References: Wikipedia – 1998 in film, Wikipedia – 1998, Wikipedia – Visual Basic, Flickr