Many many years ago when I landed my first coding job, I was amazed at how different working in a software development shop was different from what I had pictured in my mind.  At that time, I did not even graduated yet, I was in need of money and it seemed like a great opportunity so I took the job.  While driving to my new place of employment for the first time, I was running some scenarios in my head, trying to remember some tested and true algorithms, thinking of whole bunch of technical things that might help me impress my then new boss; what came as a complete surprise to me was the fact that I had no idea what the work was about.

After couple of weeks, I began to realize that many things that were part of my job were not covered in school at all.  I can’t really blame school for that, after all they were trying to give me as much information as they could about technical aspects – languages, algorithms and all that jazz, I myself had failed to learn the truth about real time work of a coder, and I did have opportunities to do so.  Later on when I became a manager and was interviewing people for coding positions, I realized that I was not unique in this lack of knowledge.  Most of the recent graduates were in the same boat that I was in years ago.

That time had passed, I learned a great deal from working on different development teams, I could probably be called a veteran of the game called software development, and today I wanted to post about things that I think any recent graduate should educate himself on:

• Time Management.
• Ability to produce accurate estimates
• Ability to write technical documentation.
• Dealing with customers – when times are good and bad.
• Dealing with co-workers in conflict situations.
• Learning is an ongoing process when coding

Lets look at those a bit closer:

Time Management

Time management  in my opinion is the most important skill a developer can have.  I would also add self discipline to this since the two are related.  It is just too easy to get distracted by things that are not really work – after all internet is right there.  Another point is getting way too involved in your project, spending way too much time on tasks that are not really that important.  It is business first, and we are all on a dead line.  Other people’s deadline is depended on you most of the time as well.  One of the biggest time wasters in  my life is email.  I get tons of messages a day, most of those need to be answered.  Most of my clients / co-workers expected me to get to that right away, well guess what?  That does not happen.  I am answering my emails at 10 am and at 4 pm.  If its urgent, people can call me, if they don’t know my phone number, then most likely it is not urgent.  It took a while to convince by boss and my client that this is the best approach to my time.  This works for me, I can’t guarantee that it will work for everyone.

Estimates

What happens most of the time is my boss tells me to code something – a feature, application, you name it.  He wants to know how soon can this be done.   In turn I go to coders and ask them – how long would it take you to do this?  Most of the coders are not able to give me an accurate estimate – and I can understand it – things happen, but could you be at least close?  I can understand if you are off by couple of weeks – my estimate will allow for that, but when you are off by month, that makes me look stupid, and guess who will look stupid next?

Technical Documentation

One of the things developers hate is to write tech documents – manuals, reports you name it.  But despite all that, you still are going to do it.  Hopefully it will not develop into full time job for you, unless you want it to.  I am not a big fan of doing it, but trust me, on top of what developers do, I actually write proposals, analysis papers, reports of various types and so on.  It is a bit of a challenge for me, since English is not my first or even second language.  So many times I had seen a talented coders who can’t write – and believe me, it creates a negative impression which should not be your goal here.

Dealing with customers

Let’s hope that in your career you will never have to speak to a pissed off customer.  We can hope all we want, but it will happen sooner or later.  If I had a penny for every time customer yelled at me, I would have a truck load of pennies by now.  I am not even going to mention a situation where a client demanded that I had  to buy lunch for his entire team simply because my plane was delayed.  I had customers tell me stuff like : “So it can’t do X, then your software is shit”.  Which was especially frustrated, because no sane person wold do X.  In all fairness, this is a way users respond to what we code, and we can’t possibly please everyone.  What I find even more frustrating is when customers do have issues, but won’t tell you anything and then the time to renew the contract is approaching and all of a sudden they don’t want to continue.  Feedback is good for you, even when it comes in a form of a pissed off customer.  Feedback is good because it will not only tell you what customers really want, but what your software is doing right.  I am not saying that you have to fold every time customer has something uncomfortable up his butt, you have to learn how to hold your ground and compromise if compromise is possible.

Dealing with co-workers

Most likely you won’t be working by yourself.  You will be in a team which would consist of several coders.  Most of us have our own personalities, favorite approaches, opinions and so on.  There are going to be conflicts and you will have to deal with it.  Conflicts are not necessary bad – at times it is the best way of solving difficult problems with features or code.  Listen, argue if you believe that you are right, but don’t start getting personal – keep in mind if the conflict is geared towards solving a coding issue, this is what you want to do.  If the conflict is about issues that are on a personal level – stay out of it.

Learning

The industry is constantly changing, there are new things coming out every day, you should be on top of the things that affect your work.  Read blogs, join a social network geared towards developers (dZone comes to mind) get yourself a mentor if you can, trust me, it will pay off.  Here is an example from my previous job – one guy just did not care, he did what he supposed to do, no learning, no progress.  The rest of the team would get raises every year, this guy – well, he did not.  Despite the fact that he was there longer then almost everyone else, his pay was the lowest on a team.  I was managing the team and tried to convince him that learning is good, he did not respond.  At the end of the day, if you will not progress, your financial compensation will not progress either.

I must admit, that this is not a full list.  You could probably come up with lots more, however to me this is what’s important.  I would love to hear from you on what you consider vital.

This would be the first time we used an external GUI dll, and I am quite happy with results. DotNetBar is a great library, and I am positive that we will use it for all our user interfaces; after all, when you have more then one app and all of those have a different look to them, kind of makes you want to re-work it all. That’s what we are doing presently.

New version of Rosetta is coming out soon too, everyone worked hard, and it feels like we are all burned out right before holidays, at least we will have few days to relax and get into the holiday spirit before going back to work.

I have been told many many times that changes are supposed to be good for you (or me, since it’s my situation that we are looking into). I have been a coder for quite some time now. I can’t say that I am absolutely ecstatic about programming. It does not influence my life outside of my office hours and time that I spent at home trying desperately to improve myself. For instance, I don’t watch Star Trek or build some kind of crazy contraptions which could loosely be called a robot in my basement, although come to think of it, that sounds like a good idea; the robot one, not the Star Trek. I don’t wear nerdy t-shirts with BSOD on it. I am not participating in heated discussions like “My IDE is bigger then yours!” and “My OS can kick your OS’s butt” and so on. I can’t say that coding is my passion, it is something I am interested in and it pays my bills. Another factor would be my formal training – I have some in development, but as for the other areas I can’t say that I am properly trained. Lately something had changed in my work – I am doing more managerial things then coding.

When I realized for the first time that this was happening to me, an image of a Pointy Haired Boss came to my mind. I quickly dismissed it, since I got most of my hair intact and there is no boldness that runs in my family. But I assured myself that I will keep on coding despite the changes. It becomes more and more difficult with every day. I still see a lot of code written by the developers on my team, I get to answer whole bunch of questions from developers as to how should they proceed with their task. At times it makes me want to ask them if google is down, but that’s not the point. Even when I get a chance to code, I have to give projects that interests me to some other people. These projects are more complex, take more time and require full concentration, and simply put, I can’t guarantee that I will be able to give these thing time and effort they deserve.

I’ve tried coding for myself – invent some little projects and making them happen – these things simply don’t work for me. I guess there is no pressure, no drive and ultimately no purpose other then to stay afloat. I still read about programming and related fields, and I read a lot, but it will never substitute the real deal – getting down and writing real life code, with all the stress, cursing, coffee spills and the rest.

To be honest, I miss the programming part of my job, but I still can give an honest question to that answer – ” Are changes good for you?”

Granted the product is very expensive (more expensive then VS 2008 and Adobe CS3 suite combined) and this sometimes can inspire our clients to demand stuff.  We’ve been through this before.  A company that shell remain nameless was bossing us around for six month.  We only worked on their features, nobody else wanted these things and at the end of six month they said, “You know, this is what we said we need, but not what we actually need”.  I can still remember that conversation.  Incidentally this is the time when my first “Punch Box” appeared at the office; since then we went though a number of  “Punch Boxes” and that was the end of that.

Three times in the last 4 years we went through similar situations, and we have yet secure a contract when too much custom stuff is put in and we basically keep on asking “How high”.  This is the fourth time.

We have to release a newest version on Tuesday, Sept 30, so everyone is up to their necks in testing and bug fixing when all of a sudden “dll hell” makes appearance.  Everyone who coded for Windows knows what I am talking about – one guy decides to mess around with perfectly good reference and all hell breaks loose.  Today its Microsoft.Office.Core.  Nobody can compile, nothing runs, and we can’t roll back.  Unfortunately we have to rely on external references such as Office.Core, because the app produces Excel and PowerPoint documents, we reference other things too, but it seems to me that whenever we are running into DLL Hell it always have something to do with a dll from Microsoft.  This is going to be a long weekend, just me, five guys, IDE and references.

Unfortunately the comments that were there did not help me at all.  Here is the problem – the developer who wrote the classes I needed to modify went out of his way to block a certain type of input by user.  Input strings were checked couple of times as well as an event was called to verify input on every key press.  And guess what – I have to have the form and the code behind to accept this type of input against which this developer fought so hard.  While it did not take me long to disable these road blocks, I still can’t understand why were these things blocked.

The comments were there, and they were describing what was the code doing and not why.  Realistically speaking, any developer can read code and get some idea what is happening, you don’t need to comment it, I was searching for an explanation why and I did not find it.   There was no unit testing provided, so I have no idea what my changes do to the stuff that was already written and I have no reason to be certain what will happen to the code until we test it, and trust me, this will be the most tested area for this new release.  Did I needed to see explanation of how a foreach loop is executed – no; would I love to see explanation why this input was blocked – YES.

When I joined RS team, well, there was no team.  There was Matt, the guy who came up with the concept and there was me.  Rosetta then was in v 1.2, so we did not have many features implemented, basically the app was so vanilla, we only had 2 clients.  We had lots of ideas, and very little time and patience to maintain some kind of development system that would help is stay on course.  On top of coding, we had to do sales and support plus we were expected to help everyone else with their computer related problems (like fixing Outlook and writing Excel macros).  All this left very little time for development, and we had potential clients breathing down our necks twisting our arms to get the features they wanted implemented soon.

We were working in a fire brigade mode, there were fires, and we had to put them out fast.  There was very little time to think about writing optimized and efficient code.  As long as it worked, it was good enough.  This might appear as a good model for someone with a new app, features are added quickly, we had releases quarterly, our client base grew and soon we realized that we don’t need to put out fires.  We still have a list of suggestions (which actually more like demands then suggestions) and we are working on those, but now there is no rush to get it done, so we are doing it properly now.  Matt is gone now, I lead development team, and we got enough coders to maintain a good pace and write quality code.  But the stuff that was written in the past is not going away.

Right now we are rewriting Rosetta from scratch.  We need to adapt to the new framework, plus Office 2007 and localization and let me tell you, it’s a lot of work.  To address the issues of the old code, and believe me, I was thinking about it for quite some time I came up with this weekly code reviews.  Now every week one of us takes a function from those old classes and rewrite it in the most efficient way the developer can imagine.  Then, the developer has to present his work to everyone, explain briefly what the class and the function is all about, what and why was changed as well as measurable benefits of the change.  I thought that first of all we will slowly start changing the code, which when done properly is a good thing, some of us get exposure to classes that we never worked with before and we would share some of or knowledge.  To start it, I decided to go first.

Picked up a function, shaved some time on execution, dropped a loop, did some smaller things.  Just to make sure everyone is paying attention put some goofy things with appending a space to a string and then trimming the end of it.  Everyone caught it right away; I guess the guys are responding to this new idea.  We’ll see how will it progress, but basically I would recommend this to everyone running a small development team as a good exercise and learning experience.

During this year, we lost code.  There was a very bad case of it when we spent 3 days hunting down a bug and then fixing it only to notice that somehow the changes did not registered with Source Safe.  There is also issue of branching and merging – I have to say that when I am forced to do branching it completely ruins my day.  After branching is done, I am usually grumpy and unapproachable.  With merging, its like that famous line from Forrest Gump – you never know what are you’re gonna get.

After doing some research, I think Subversion should work better.  There is only one tiny problem – I can’t find a good unbloated tutorial on how to get this thing started.  I know, RTFM but who has time for that?  For the next few days I will try to get Subversion work for us.  If I will come up with a simple way of getting it going, I will post a short tutorial, probably just for myself, for future reference.

This has been a very difficult release to prepare.  We just hired another great developer – Will who despite my expectation did not require much of hand-holding and was able to just dive into it and make some great things happen.  My other guys had to do features with no set of final specs, it seemed to change with every week but managed to do great so far.  Considering the fact that our support guy Paul was doing lot’s of travel and we had to pick up those duties as well, we did reasonably well.  Dave is supposed to announce this release at the conference at the end of the month, would be great if we could actually finish it by then.

Actually after this release Dave is planning on visiting most of our clients and having a talk about the direction the software is going.  Should be good as we love getting realistic feedback and not just generic – “Look good, will probably use it”.

When I came to then ATP Canada, Rosetta was 1.3.  We had two developers – Matt and I; back then we had to work as a fire brigade all the time.  We also managed sales and support as well as coding.  Now we are looking at 3.1, have great team of developers, dedicated support / sales person and things are looking very optimistic.

I am actually looking forward to this release, after this one there are going to be some major changes in product lines and frameworks, should be fun.