Spell Check Your Resume

I got an email from a guy at my company who is looking for a project. I guess he needs to get placed or he is out of work. So I took a peek at his resume. One of the first things I saw was that he listed his maticulous [sic] trait. Oh boy. We might be in trouble.

It was a bit funny but sad too. How meticulous can you be if you cannot spell meticulous? At least run your resume through a spell checker and correct the problems before blasting your resume out to strangers. Otherwise you will face peril.

I took a closer look at the resume. Seems like the guy is going to college to get his degree. Not sure how my company hired him. I tried to get a rock star college student hired. Was told that we only hire college grads from good colleges here. Go figure.

Middle Management

When I first joined my company, there was a team of managers on the project. They worked hard. There was a lot of work to do. I got used to them. Then something happened. I suspect they got tired of working hard. What did they do? They hired their replacements.

Well replacement might be the wrong name. They hired new middle managers and called them the delivery management team. Now the senior managers sit back and let the middle managers handle all the muck. We have a lot of middle managers working hard.

My own team has been dwindling down due to attrition and reassignment of team members to other initiatives. We each have more responsibility. Oh well. My team is now small. I took a vacation last week. When I came back, the team lead had also taken some time off.

The delivery manager in charge of us seems to have a plan of his own. He wants to delegate down to the team leaders. And when my team lead is out, I guess the buck stops with me. Now doing management by itself might not be evil. But I don't want to manage when I also need to turn around and do most of the actual work.

I call shennanigans. Definitely don't want to end up doing a middle manager's job. Not at all.

Ooops I Did It Again

Was reading a forum talking about some big tech company laying off all their employees. Ouch. Different people were talking about opportunities for these employees on the forum. I suspect these may have just been some recruiters looking to cash in.

On such recruiter listed the needs they were looking for. Lot of requirements looked familiar such as experience with PHP, MySQL, JavaScript, jQuery, etc. Then there was a line describing the need for programming skills and strong OOPS. Umm LOL? Either they were trying to comminicate a need for Object Oriented Programming, or they are talking about a new OOPS acronym I don't know about, or they are singing Britney Spears songs.

Ha ha. That's going to be my new methodology. OOPS. Just have to come with a catchy algorithm and run with it. Heck it sounds close enough to OOP that I might just be onto something.

Metadata

I have an action item for my yearly review to propose a major change to any of our systems. That should be easy. I want to make my proposal beneficial to me. So I looked around for a pain point. I got a lot of yearly maintenance to do with our hard coded SQL. Maybe I could address that.

Metadata to the rescue. I could store all the info about the tables and columns in a metadata store. Then a query builder could interrogate the metadata and build up my SQL strings on the fly. Maintenance of the metadata will be a whole lot easier than going through all the hard coded SQL.

Had a manager call me up today to discuss my proposal. He tried to drill down into the structure of the metadata. Unfortunately he did not fully understand the problem being solved. He also pitched a very verbose metadata structure. I want my job to be a whole lot easier. Don’t want to shift all the hard work from code changing to metadata maintenance. Got to formulate a plan to get him to see things my way.

Methodology

A developer asked me for some help today. He tested out his code and threw it over the wall to the test team. They said his stuff did not work. Then he tried his code again. Sure enough it was broke. He could debug the C++ code using his Microsoft IDE. However he was stuck once it called some stored procedures in Oracle.

I told him the thing to do would be to activate some logging so he could build a bread crumb trail. That way he could figure out what was going on in the stored procedures. I call this the old printf style of debugging. So we sprinked some logging to a database table in his routines. Then we ran the code again.

Sure enough, some output was generated in the database table. We traced it down to the code he wrote. Then we iterated and added more logging in the local area where he thought the code was not working. All of a sudden, the application started working correctly. Wait what? I could not imagine just adding logging would fix the problem.

I gave it some thought. The logging did not magically fix his code. He was just not running the same version of the code that he was looking at. He just assumed that the version of code he worked on was what was deployed. Next time I should have him extract the source code of the stored procedures right out of the database. That would prevent this surprise.

Debugging Skills

I have not taken much time off this summer. Last week I took a day off from work. Needed to help a friend with some heavy lifting. Got a call while I was out. Apparently a system that I maintain had problems. I told my boss that I would be in the next day. However someone else could surely resolve the issue.

Turns out my normal backup was also out of the office. That's okay. I trained the new guy on this system. Unfortuantely he told the managers that he knew nothing about the operations. Fail. I guess I trained him up but he did not use that knowledge. So he forgot it all.

Today I was scheduled to give a one hour session on the system. I did so. Took around 30 minutes to give a high level overview plus a hands on demonstration on how all the pieces get run. Then a manager asked me to prep the audience to respond to problems. Another manager asked that I give them the steps to "reset the data".

Unfortunately the only way to get familiar with the system is to get your hands dirty. You got to resolve a bunch of trouble tickets. Only then will you get the chance to dig deep and understand what the heck is going on. That's how I learned. That's how my backup learned. And that's how everyone else is going to need to learn. Sorry. Once again there is no silver bullet here.

Programming Languages and Pay

Read a few articles today on computer languages and technologies, plus their effect on your salary. Here is one thing for sure. New developers would be smart to add the following technologies to their tool belt:

• JavaScript
• Java
• HTML
• SQL
• CSS
• .net

It would also help to learn some lesser desired skills such as:

• Linux
• C#
• jQuery
• PHP
• ASP
• Python
• C++
• MySQL

That being said, in some markets, technology does not matter by the time you are a senior developer. Let's say you want to work at a startup. And let's say you are willing to relocate to the San Francisco Bay area. Then you just need to have experience in a skill such as:

• Java
• JavaScript
• Python
• C++
• HTML5
• Ruby

If you are good, and have a lot of experience, you will be highly compensated. The downside is that it costs a lot of money to live in the Bay area. But at least you will be able to get a job that pays well. So says top recruiting firms for startups in the area.

Surprise Requirements

I was working on designing solutions to some new client needs recently. Our process is to map all requirements to sections of our design. It is a little tricky when more than one team works on a set of requirements. I mapped those requirements I thought my team fulfilled. Then I passed the mapping document over to the other team involved.

Sometimes I am able to detect some requirements that are not necessarily new. They are just newly documented. It is a problem that they are just lumped together with the new requirements. But that is a story for another post. There were there requirements at the end of my mapping which seemed strange to me. They did not seem to be related to the new functionality. They also did not seem to be things the system already did.

I decided to get in touch with our requirements lead. Apparently these were requirements previously collected but never implemented. They need to be completed along with all the changes I am working on. That is a bit tricky. They should not be mapped to the new design I produced. They need to go with a future design that was yet to be written. Tricky.

Timesheet Recording

The suits on the project want to record how much time we actually spend working on new features. They think we are spending too much time on them. Guess what? They are half right. We are spending a lot of calendar time ... doing things other than working on new features.

The little time we actually spend on the new features causes the schedule to drag on. Our team decided to record the time we spend on tasks during the day. Iteration one is using Excel spreadsheets to track everything. Hey. I am game for anything that tracks actuals.

Initially the team wanted me to record start and stop times for tasks. Dude. I work on all kinds of tasks and get interrupted from each all the time. There is no time (no pun intended) to record all those starts and stops. The goal here is to collect duration of tasks. Therefore I am only record the daily duration on every task I do.

The team lead thought we should record down to the 15 minute increment. Nope. Thirty minutes is the least I can do. Otherwise I am going to be wasting more time recording the stuff. Pretty soon I hope we can use a tool to collect this data. But spreadsheets are good enough for right now. I find that I am even more diligent in recording everything I do, including all the interruptions.

The Use of Metrics

Our project does a lot of estimation for new work we shall perform. The customer uses that information to determine how many new things we can handle per release. Recently there has been a push to collect actuals on how much time we spend on this new work. Must be some type of CMMi activity.

This is the trick for collecting metrics. You don't want the job of collecting the metrics to take up a lot of time. You also want it to be accurate. I remember when I used to track the time we spent fixing each bug. I had to collect all the info. Then I would put out reports on the subject. I did this until I was able to convince my boss that it was not time well spent.

I had thought that the goal for this new metrics collection would be to fine tune our estimation process. That way we can have more accurate projections on how long new work will take. My manager said he thinks this will help us report status on the new work as well. Let's just hope I don't have to start spending my life collecting metrics from the team.

Drawbacks of Being a Guru

I have been working on my project at work for almost 15 years. See it all on the project. Been involved with a lot of pieces of it. So I usually know about things that go on. That's great when I want to get stuff done. I got the business info.

Other people lean on me for help. Hey. That's usually not a problem. I can give some good developers a few pointers. It will help them cut through a lot of confusion to get their work done.

However there is some abuse of my help. Slackers want me to hold their hand while they do their work. That might benefit them. But I got my own job to do. Can't let people waste my time. Not sure how to communicate this to the slackers. Maybe I will just not take their calls.

Schedule Estimating Software

We have customer requests for enhancements to our legacy system all the time. The customer first needs an estimate as to how long it will take to develop, and thus how much it will cost. The way we respond is that we first try to figure out what it is exactly that the customer wants.

Then we get experts to think about a type of design in their mind. Once such a design has some meat, we will try to count up all the parts it will take to implement that design. This includes different GUI screens, interfaces, database code, and so on.

Once we know the pieces of the implementation, we decide to quantify them and rank them as being easy/medium/hard. Then we plug in how experenced the resources are that will implement the solution. This all goes into an Excel spreadsheet that has some smarts built into it. The result is a number of hours it will take for software completion.

Wouldn't it be easier if we did not have to rely on the experts to do all this analysis? I would like to send a business developer out to the customer, and have them be able to quickly estimate what the work is going to cost. We need something like Software Schedule Estimator for this job.

Wrong Estimates

Some performance problem popped up in our production environment. A bunch of us developers got together and sketched out possible solutions. We brought in some DBAs and came up with an optimal approach. After this initial huddle, a manager and developer went off to research the solution further.

This weekend I got the notice that I needed to implement the solution ASAP. Then I was asked for an estimate on how long it would take to knock this out. I used my trusty estimator spreadsheet. I have found it to work pretty well. Since we already designed a solution, I cut out the design hours.

On day one, I tried to manually check out the solution. Oooops. The SQL would not compile. I spent a day struggling with it. I called in a bunch of managers, developers, and DBAs. At first nobody else could get the design to work. Eventually a DBA and developer came up with a related desgn that would work. Problem was that now I was a day behind schedule.

Design

I am working on a new change for our system. This has been a rush job. All jobs are rush. But this one is really a rush. I started to think we were in trouble when a requirements analyst asked me for questions, then was unable to answer them. You can’t meet rushed schedules if you don’t know what you are doing. I decided to just go with some assumptions and run with them.

I knocked out a design document for my changes. This document assumed you already knew how the existing system worked. It also assumed that you knew what the new changes were about. My goal was to make sure a coder could read the design and immediately implement the thing.

A day before the customer was supposed to receive my design document, I passed it to some managers for review. One of the managers was new. He did not know what I was talking about in my design. Well yes, it was written for system experts. I did take the comments and reformatted my design. I wrote it from the viewpoint of a newbie.

Luckily I left the pseudo code section the same. That is the most important section. I got PL/SQL code in there that is pretty close to ready to compile. Now that does not mean you have to cut and paste my code verbatim. But if you know PL/SQL syntax, you will know exactly what you need to code.

More Requirements

I have to roll out a new feature for our customer's system really soon. Since everything is rushed on this job, the requirements analysis team needed to step it into high gear. I was required to attend a few meetings. In the kickoff meeting, some ideas were thrown around. Then the floor was open to questions. I asked some details about the main flow of the feature. The result was that I was asked to go research the answers for the details. WTF?

After getting assigned some action items based on my questions, I clammed up. I am the developer on the project. I write, test, and roll out the code. Requirements analysis is not my responsibility. I don't have the time to take on a second job on the project. Somehow the requirements phase is being run in a backwards way.

Since I have to actually produce the features, I will need some requirements analysis done. However I can do that on my own when I am rocking and rolling on the design phase. There is no reason for me to do all the work, but have to slow down for some requirements analysts to just try to get me to do all the work for them. Not good.