Imagine this, you are a seasoned web developer and have encountered just about every situation as a developer. Now imagine that an unseasoned developer, not quite under your care, stresses that something that is overly basic – as a seasoned developer it would be overly basic – can’t be done or require just way to much time to achieve. Now imagine since this developer can’t (or won’t) do this overly simple task you now have to take this project on your shoulders and spend countless hours recoding close to 500 lines of code plus add an extra 300 lines of bloat – all of which are against your better judgment and coding philosophy – to achieve the goals for this project. How would you react? What would you do? Well, I will tell you how I originally reacted and what I eventually did.
My initial reaction was poor, very poor and embarrassing, I flipped out and stopped short of calling him name.
My initial reaction was poor, very poor and embarrassing, I flipped out and stopped short of calling him name. I did yell, which I never do. When the project was start all requirements were laid out and I explicitly told the developer exactly what I needed and made him repeat those needs back to me. I also ask him what he need from me and I confirmed those items with him in emails, in person and on conference calls. So when you get a call on a Sunday afternoon stating that you have recode code that has been done for over a month and a half that has been tested and was working a 100%, getting mad is just about all you can do. So I yelled and cursed; recited email after email, notes after notes about prior discussions and what was agreed on.
Like I said, reacted very poorly. After this call I stepped outside to collect myself and get my thoughts together. Once I calmed down I decided that I would treat this situation as if I were back being a supervisor at UPS. What made me one of the best – if not the best – supervisors at UPS was my ability to train, cross-train, communicate and making my employees think that my ideas were actually their ideas.
…debating only waste time and will frustrate you.
I went ahead and did all the recoding and set things up to have this developer come up with my ideas. At UPS having someone come up with your idea was pretty easy, it’s manual labor so convincing someone to do something smart not hard is quite simple. Convincing a person that sits in front of a keyboard that you never see (I telecommute) to work smarter, not harder is complicated. I had to keep in constant communication with him and our supervisor – our supervisor works in the office with him and can relay messages to him without making it seem like it came from me. In these communications I had to bring up a small problem that only really had one outcome and would be the outcome I was looking for. Much like a lawyer should never ask a question they don’t already know the answer too, I made sure to ask questions that only benefited my philosophy. I tried to stay away from items that I knew would cause a debate, even if in my mind it was a simple topic, debating only waste time and will frustrate you.
After about three weeks – yes, three weeks is a long time but keep in mind that I don’t see this person everyday and I am working four other projects so very little time to focus – we were getting complaints that the app was moving too slow. Which was one of the seeds I was planting over the three weeks was about load time and processing time. I had gone into the office to discuss everything face to face with him and our supervisor to see “what we can do to fix it.” I had planted quite a few seeds so all I really needed to do at this point was to add water. Water in this instance was me walking thru that app looking ever-so frustrated that I could not come up with an answer on fixing it. I start out by pointing out the the obvious, the page took too long to load and once we were sure everything was loaded there was still a hand in the app. The load time was do to a massive XML document being loaded, well over 4,000 lines, and the hand was the bloated code I needed to put in to achieve what this developer could not do on his end.
…sometimes you have to baby step people till the see the big picture.
After pointing out exact what might be causing the load time and the hand, xml and the code bloat, I suggested something simple for the load time in the form of a question to the developer. “What would happen if we shrunk the tag name for one specific tag in the XML down to one letter?” He was like “Hmmm… the change would be pretty easy on my end, maybe we comment out some attributes that are not needed.” And that is where he started taking off with the idea (please note, this was one of the ideas I’ve been pushing from the very beginning but its only a band-aide to a bigger problem. Baby steps.) and shrinking the other tags. Basically were shrank a 500kb file down to 250kb, not great, but a huge improvement, remember, sometimes you have to baby step people till the see the big picture.
Once we got that particular issue “resolved” it was time to move onto issue two, the code bloat. When I coded this I made sure to make it expendable, the moment it was not needed anymore it was gone. The framework basically works off the hash by default, much like gmail does so you can go back and forth in your history. But instead of sending me the hash as my code expects, he was sending me an ID of the page and I had to transverse the XML to build out the needed hash. But before I had the chance to start explaining the problem and how we “might” resolve it he blurts out “Oh, I think I can just send you the hash. Shouldn’t be to hard.” I litterally sat there with my mouth open for what felt like an hour. To rehash, the number one issue that he was unable to do was the building out of the hash. For those that don’t know, a hash is what you see in your URI (#somehash). In our case, the hash looks like #m-1000-0-0-0 which is #m-Module-lesson-topic-page; its zero based so 0 is the first lesson/topic/page, 1 is the second and so on.
So what did we learn here? Well, a few things.
For Senior Developers:
- Be willing to let the unseasoned learn from their own mistakes. You may need to take a hit every now and then but in the end the unseasoned will become season and an asset.
- You are allowed to get mad and frustrated, but keep your composure. Step outside and take a breather if you need, but keep your cool and be a leader.
- You made your mistakes to get where you are at, so remember that when the unseasoned make a mistake that makes your work harder to do.
- Be willing to teach, that kinda goes hand in hand with letting the unseasoned make mistakes, but the difference here is preemptive. If you have an opportunity to truly explain why something is done a certain way, do it.
For Juniour/Entry level Developers
- Learn from your mistakes; don’t make the same ones over and over again.
- Understand that people will get frustrated with you if you “don’t know everything they know.” But be willing to ask for help. 99% of the time that will bring the frustration level down and give them an ego boost.
- This one bares repeating: Learn from your mistakes; don’t make the same ones over and over again.
- Be willing to learn. Simple as that. You don’t know everything and there is always someone, even for seasoned developers, that knows much more than you.