A couple of bumper stickers I like
The Universe - Love it or leave itIt's Easy to Walk on Water when The Requirements are FrozenNever Attribute to Malice What Can Adequately Explained by StupidityHave You Been Saved - or at Least Recently Backed Up?What's the difference between a used car salesman and a software salesman? The used car salesman know when he's lying.The shortest difference between two puns is a straight line.If you're not part of the solution, you're part of the precipitate.186,000 miles per second - it's not just a good idea, it's the Law!
Always check your backups by restoring!
On at least 3 occasions in the past I have been burned by backups that "looked" like they worked, but when the file was restored the actual contents were missing. So I don't consider any backup strategy valid until I have done a live restore. If I'm working with a separate backup group, as is the case in any reasonable size IT shop, I request a specific file be restored from a given day.
This also gives me experience in the procedures for a doing a restore. You'd be surprised how difficult it can be to get this accomplished. Backup departments are structured to do exactly that - back things up. Restoring is an afterthought at best. Be persistant. Follow up. The last thing you want to happen is to find out the backups are messed up when you are actually counting on them.
Same is true for DR (Disaster Recovery)...but that's a different post.
Allow your blog posts to age
Well, I've defintely done that on this one. I'm new to blogging, but like anything else I've written, I've found it's better to let things stew for a while before I actually commit or send them. This gives the ideas time to settle down and thoughts often come clearer, at least for me. Also, it allows one to remove potentially embarrassing statements written when one is, perhaps, somewhat less rational. I'd be interested in others views on this.
Always strive to eliminate your current job
This is a piece of career advice that I've given out quite a lot during various mentoring sessions I've had with co-workers. It often seems counter-intuitive to less experienced people but this is a simple fact I have learned:
Eliminating your job leads to better job security.
In a prior job, I was promoted 4 times. Each time was as a result of eliminating my prior job. I came in as a regular programmer/analyst and was promoted to Sr. P/A after getting a system running to the point where any operator could handle it. I was promoted into a new job title (that I pioneered) called Technical Analyst after getting the group I was running going so smoothly that the work it was doing could be handled by a single developer. I was promoted to Technical Analyst 2 after I got the system configuration issues I was managing to the point where they could be handled routinely.
A caveat on the above. There were many factors surrounding the promotions in question. This particular technique is not the only reason I earned them. I have also worked myself out of positions many other times that resulted in lateral moves -- but always in situations where I had input in to what the move was.
The point is that when you work yourself out of a job, it makes it clear that you are ready for more advanced responsibilities. By eliminating the job in question, you have freed yourself up to take them. When I did this, I was seen as a dynamic, team player with the best interests of the company at heart, because I was willing to "sacrifice" my job for the good of the company.
On the flip side, I have seen people who have been grimly hanging on to their job. They react badly to anything that seems like a threat to it. This often leads to hording of information, poor teamwork and bottlenecking. If the correct position is chosen, the person can
seem like they are in a strong position. However, this is only a short term effect (short can be as long as several years). Companies will start working around the bottleneck and eventually route around it. What was once a critical, highly visible position will become a legacy position, which the person can not get out of exactly because of the work they have done to protect it. If the position is eventually eliminated, the person often is as well because no other team wants them.
View the glass as already broken. Your job is already gone. Which one do you want next?
Why I don't give technical advice...
After 25 years, I've seen a lot of technologies, techniques and tools come and go. I've worked with a lot of developers. Any decent developer can pick up technologies by the bucketful. While sharing these things are valuable my experienced is so varied, however, I don't have much depth of technique to hand out. There are many places to get that kind of information such
Code Better. Developers as a class suck at soft skills though and that's what I've spent a good chunk of my career having to cope with (because I have little native talent in that area, as well).
So most of my posts appear to be dealing with the softer side of development. Just an FYI.
Making sure people hear what you mean to say.
My experience with developers (including myself) is that we have very precise denotations and pay no attention to the connotations. That is, we look at the literal meanings of what we say and not necessarily how it sounds.
By this, I do not mean that we don't understand or use colloquialisms. I mean that we don't take into account what our audience is hearing. Computers have precise, if sometimes frustrating, interpretations of language. People do not. So what we say is not what they hear.
A good way to make sure you are being understood is to ask the person to echo what you've said. This is also a good way to make sure that you understand what someone else is saying.
Never ascribe to malice that which can be adequately explained by stupidity.
Hanlon's Razor is often a useful thing to remember when dealing with people issues, especially developers. Trust is the key to effective team work. Paranoia destroys trust. The best way to handle problems is two-fold.
First, always assume the best reasonable possible intentions on the person who is causing the problem. This allows a discussion of the problem in a rational light. Also, intentions are difficult to discern and virtually impossible to prove. So working on the objective issue depersonalizes it and allows a solution to be reached more quickly and effectively.
Second - always maximize your own fault in the situation. This has two good effects. One, it puts other people at ease because if you start by taking responsibility, you aren't looking for a scapegoat. Also, it means that you have a legitimate reason for dealing with the issue.
I am not suggesting lying or exaggerating the level of involvement here. That shades in to manipulation and will probably backfire. If you have no involvement in the problem then you should not be talking about it -- MYOB occurs to me. If you have responsibility in the area, then you are also responsible for the problem. Figuring that out and how it applies is the best exercise keeping a clear idea on how to solve.
Comment on grammar
I've grappled with the general problem of not having a pronoun that deals with people whose sex is not known (or releveant). We have he or she. The word "it" deals with sexless objects as opposed to indeterminate sex. My compromise solution is to always use they, even when the reference is only one person. I would rather mess up on number than gender.
Anyway, I thought I would post this, in case anyone thinks I am incapable of doing pronoun - referent matching.
Don't Allow Your Team to be Locally Optimized
The current team I work with has four developers with strong skills in individual areas. One is a great web guy, one an O-O guru, one a genius build manager -- and then there's me. Last year we were working on a project and everyone went heads down. When we came up for air later in the day, we realized that we had missed some things and duplicated others. What happened?
Well, we were each working our own areas, where we
knew what we were doing. We knew we knew more than anyone else. So we didn't talk -- and we missed things. The team always knows more than the individual. We were locally optimized, but not optimized as a team.
The best way that I've found to deal with this is to using the Agile concept of
pairing. The stronger partner in the pair
does not drive. In this case, the stronger partner is acting a mentor for the less expereienced developer. This generally works extremely well. Not only does it end up cross-training the group, but it also forces the "expert" to ask themselves questions they may not have thought about in a while. In a well functioning team, this will surface issues that the whole team may need to discuss. In a local optimization scenario, since the "expert" is tacitly delegated control over the area, they may not think to ask for the teams input.
Do A Test Run
I'm sitting here while we do a production push and thinking about how things are going. One of the things that is giving us a great deal of confidence about the push is that we did a complete run through on our test environment - including a rollback of the old code.
This may seem like an obvious thing, but it's easy to skip and not always easy to do. Often test environments are crippled versions of production, missing essential pieces. So sometimes it's very difficult to test those pieces. For instance, if your application makes external calls, the called apps may not be present or only present in stub form -- so the configuration and set up for those pieces are not being tested in your dry run.
Also, if you've QA'ed (and I don't want to hear if you don't) your app and done an extensive amount of testing, it may be easy to think "it works -- what could go wrong?". Lots of things. Missed files, missed configurations, invalid objects, out of sync versions etc. Any one of these can cause the system to fail in a dramatic way.
By doing a dry run, you at least make sure that the components are all present. Of course, this assumes that you at least
smoke test the system after you've installed it. At the very least this gives everyone involved in the install a chance to understand what is going in a very pragmatic and practical way.
Do We Give Customers What They Want or What They Need?
One of the things I've learned is that people rarely know what they want, especially in the detailed sense required to develop software. They have a problem and they want a solution. Quite often they have a solution in mind...and it doesn't solve the problem. This is where the experienced developer can make a big difference.
Figure out the problem the customer is trying to solve. Then walk backwards through their solution until you get to a point that defines what the problem is. This is often a considerable distance from where you started. Work on the problem from there.
To take an extreme example, a user may come to you and say "We need to give all the users administrative access to the system." Your first reaction is to say "no way" and walk away. However, the user has a problem they are trying to solve. So a good question to ask might be "What do they need it for?" But that sounds negative...so a better question might be "What problem are you solving with this?" Be open. Listen. Chances are there is a way around the problem -- maybe one user can act as an administrator for a group. Maybe a more limited level of security can be given. Perhaps the system needs a new feature. Actually, many times in this situation, I've found the system already has the required feature, but the user in question is unaware of it, or hasn't thought of it in the context of the problem.
Sometimes this approach doesn't work, though. The customer wants the solution they want and won't listen to anything else. So you may also have to give them what they
want as well as what they
need in order to get them to accept the solution. Many developers do one or the other, not both. Both are necessary. If you don't give them what they want, they won't accept the solution. If you don't give them what they need, the solution won't work. So both parts are necessary.
Hello World
I have been convinced by my various compatriots (including
Jeremy Miller and
Jeffery Palermo) that I might have something that is worth saying. I've been in and out of development for over 25 years, so I suppose it's possible that I've learned something. We'll see.
I'm calling it the Archived Developer, because it I'm constantly pulling information out of the archive in my brain (with the requisite waits as the tapes load). The theme I'm starting with is "the more things change...".
A little history. I started my love affair with computers in high school in 1977. It was at
Oswego High School on a computer affectionately known as 'Igor'. It was an HP 2116C with 8K of ram, 4k available after the BASIC intepreter loaded.
I got a part time job in college as a developer, working on a degree in Mathematics. Somehow I never worked in my degree field and stayed with computers. I worked through a bunch of small companies in the 80's, a large one in the 90' mostly in IT. Now, I'm actually a developer, back in a small company again. I eventually got a Masters in Software Engineering in 1998, so I suppose I finally did match my education and my career.
Along the way I jumped from CPM to MS/DOS to DOS/VSE to Xenix to OS/400 to Unix with various side trips in Windows along the way. I've worked in almost all the brands of BASIC, various COBOL's, a few dialects of RPG, Java and lately, C#.
DisclaimerAll views expressed in this Blog are my own and do not represent those of any other person, company, corporation, society, organization, nation, state, republic, entity or alien living or dead [unless they are one of the others that are also resident inside my head].
