Since I’m new to the blogging space, I thought I’d try writing about my experience in a project at work I just finished up.
What I Learned: The One-Minute Version
Overall, the project was a success. My success criteria are that the project fulfills the requirements laid out for it, the customer is satisfied, and most importantly, the code I’ve written is considered clean code.
What I learned from this project can be classed under three categories, deadlines, data calculations, and feedback. Deadlines should be given only when you have all information available. When calculating data, it’s more important to know what the client wants rather than what they think they already have. Finally, communicating with your clients will always be a challenge but when it comes down to it, the client needs to be responding to your questions in a timely manner if they wish for their project to be completed likewise.
How Did I Come to Those Conclusions?
Below I go into more depth of what I experienced and learned from my first high visibility project.
Deadlines: To Commit, or Not to Commit?
One thing about this project, and maybe it’s similar to most projects, but it seemed to have a lot of urgency early on. The leader asked for it right away and “joked” to have a deadline by the next holiday which was less than 2 months away. Safe to say, that was not the deadline that happened. Once the project status was updated consistently, the stakeholders were a lot happier and the “urgency” slowly went away.
Each time a new project is started, people will try and pin you down to make a hard deadline; there’s no need. Depending on the leader and the level they’re at if you’re able to give consistent updates without committing to date; do that. If you can’t, and you’re forced to make a deadline, make sure you do it with all the information available. Never let someone who has more “power” bully you into giving a deadline you’re not ready to commit to. I read an article where a leader was continuing to pressure a developer for a deadline date before the developer had a chance to gather all the relevant data. After attempting to placant the insistent leader, the developer finally said,
“My performance is always at its maximum, and it is non-negotiable. I work at 100%. Less than that would be wasteful, and more than 100% is impossible by definition.”
After running through the usual responses and telling the client you need more time, sometimes you’ll need a more forceful response to let them know you’re not to be persuaded. It helps if you hold to a specific mantra and idea with your work.
I actually implemented something on this project from the book 48 Laws of Power by Robert Greene. In that book, law #20 stated: “Do Not Commit To Anyone”. The idea behind it is that you are not rushing in to take a side and you’re committed to working for yourself. When you don’t commit, you make yourself desirable and become a “master of others.” While I only did this with a date for the project deadline, I think it still allowed me to have the flexibility and not be pushed into a date that would force me into long stressful hours or look like a fool if I missed the deadline.
Data Calculations: Where is the Correct Source?
The project was currently residing in an excel document that someone manually created each month. There were multiple pages of data that was exported then manipulated into the correct format for the specifics of the project. This took the person many hours to work on and formulate properly and in the end, it would sometimes be filled with data inconsistencies or in another scenario, it was difficult to change the calculations on the fly. The funny thing about the whole downloading the data and putting it into a single excel spreadsheet was the data was from the databases that I could work from. It was essentially a very roundabout way of getting the data, so that’s where my part started. I had to pull the data from the source and manipulate it into the correct format from there.
This was a little more challenging than I originally thought. I first had to understand the process by which the person created his data and where he was going to get it. After that, it was a matter of reverse engineering where he got his data and grabbed it from the source rather than through the formatted reports.
Finally, I would have to calculate it in a similar if not exact way that the person used on their excel spreadsheet. For the first part of the project, I followed this path and worked to duplicate the person’s efforts but by circumventing the extra steps to get the data. That’s when it’s good to know the people who created the data.
When I started spewing out numbers, some of them did not look correct. Diving in more, I contacted the person who originally created the said data. He confirmed with me that the numbers I had were not correct at all. This was the point that I learned to not always trust your client’s sources and calculations.
I learned that you need to delve into the request and ask why and what it is exactly they are looking for. Even if they have the calculations and data given to you, it’s still best to check the sources and verify with someone closer to the source of the data.
Feedback & Communication: Is There an Easier Way to Receive Feedback from Busy Clients?
One of the issues in this project was trying to get feedback from people who are important and have a lot of responsibility. It’s almost easier to send the email out to them, go work on something else the rest of the day and then check your email the next morning, fix their feedback, rinse and repeat.
Throughout this project, I was waiting on the leaders multiple times which was frustrating when their approval is needed to release.
Is there a better way to get feedback from busy leaders? Maybe a better question to ask would be, is there a better system for getting feedback that doesn’t slow your productivity and works into the schedules of your client?
One thought process that is easy to fall into is thinking that you, as the developer, deserve to be at the beck and call of the client because you’re the one creating this tool for the client, so they should be helping you with anything and everything asked immediately. While this thought process is true to an extent, there has to be a way to expand farther than that.
Everyone is busy and we all have important tasks to accomplish so it’s worth coming up with a better idea with communicating to your clients. I personally have not found the best solution yet but I have continued to acquire experience.
In the end, what I continue to believe until I stumble upon a better way, if they want something to get done, it’s on them to make sure they give enough attention in a timely manner. Your time is worth just as much as someone else’s.
Clean Code: The Most Important Step??
The last thing I learned and received experience for was the reinforcement of using clean code.
After you’re finished with this project, there are about 20 other things that are calling for your name. That’s why it’s so vital to take the extra couple of hours to refactor your code in a clean and concise manner. It will save you more time down the line or a fellow co-developer’s time.
Overall, the project was a success and I learned a lot. I hope this post helps teach people more about project management as a developer.