What is taking ownership of your code?
We know this phrase from the great Bible of corpo-jargon, but do you know what it means to be involved in a project? Being involved is a good thing, and your investment can bring a lot of return. Stop being a programmer with horse shades on your eyes. Get a feel for your project, get it all over you, just like in those videos you watch of girls wrestling in bubble baths. Yes those ones. Yes, I know you watch them.
#1 Do you know your project?
No, like really. Do you understand why your client is building this project? Do you see the potential it can bring if when it becomes successful?
Noticed I crossed out "if". Every project sets out because it has a goal, a reason to exist. Usually it also involves monetary gain. Using "if" is fundamentally pessimistic. Do you want to build a project / app that is bound to fail from day one? I guess not. So don't be pessimistic. Look at your code as if it's a candidate for the next "App of the Year" award. When getting a new project, place yourself in the shoes of it's inventor, focus on the direction your client is heading towards. Consider what benefits this will bring to the nearest environment of the apps target.
Learn from & listen to your client, understand where they came from and what they want to achieve. Don't treat your client as a machine that gives out tasks on JIRA.
"The shoemaker's son always goes barefoot"
Once you know the project, and all its ins and outs you can submerge yourself in it.
We often hear that we should "make this project ours", which is a bad comparison because usually "our" personal projects (if they even exist) are slap-stick, quickly coded in the middle of the night. They hardly ever work to their fullest extent. (Do not check the source code of this page, it's disgusting, and I know it!)
"The shoemaker's son always goes barefoot" is what they say, so don't treat your project as your own, but as if it were starting in a competition you want to win.
Projects are never really "yours" anyway! Companies aren't really "your homes" and the people that work with you aren't "your family". But, since you are going to spend a large amount of time and effort in this "community" you might as well have a good time while you are there and pull your slack. Better to give your best and be proud of a month of work, than half-assing a project you despise for a year.
So be the one that notices bugs, imperfections, underperformance or any other issue that can be fixed, whether it be in the near future or something "nice to have" in later stages of development. No matter how beautiful you make your initial component, after time and several patches it might need a refactor. Reiteration is the key to success, even Rome wasn't built in a day.
#2 How to get involved?
This step is a bit tricky because this all depends on how you approach work in general, and your relations with your client. But try some of these: Become proactive and question if you have any doubts. This can be about a task, about the order of deploying things, or in general you might have an easier, or more refined idea to achieve the same thing. Your clients ideas can have flaws in them, anyones idea can have a flaw in them. Step up and suggest a better solution if you see one fit.
One thing I often do is generate a landslide of questions about a bigger task, or epic, or quarterly roadmap. Sometimes asking something as simple as: "Is this functionality for both logged in and guest users?" starts to spark new edge cases and possibly things the stakeholder didn't realise. Think about tasks you've finished in the past, and try to remember any patterns that often occur. For example a PM or PO might forget that you need to add some tracking or logging to a specific action or link. If we usually add tracking to similar things I just step up and ask: "Hey, should we add some stats tracking here?".
Usually the answer is: "oh yes sure. I must have forgotten that in the ACC". Additionally this adds another golden star to your name, because the manager will notice that you are thinking ahead.
#3 Don't over do it, be a friend
Be kind and polite, especially if you are correcting someone. Constantly monitor the behaviour and responses from your managers or colleagues. Sometimes being nit-picky and pointing out a whole load of things is a bad thing. You'll be labelled as obnoxious and being a pain in the ass.
Obviously you have to treat your clients with professionalism, but I like to add a sprinkle of personal friendship into the mix. Occasionally I ask a colleague or PM / PO how their weekend was, find out what their hobbies are and what they laugh at and what they are serious about. This allows me to draw boundaries between a good icebreaker and when shit gets serious. Be cautious with befriending a client, sure you can have a laugh once in a while, but at the end of the day you are hired to do a job. Period.
Having a balanced friendship allows for a less stressful environment. Refinement calls are more pleasant, and are more of a collaboration instead of a preaching that you must comply to within the next sprint (or else). During my refinements our PO states what is needed, what the stakeholders planned and they confront it with my ideas and technical knowledge. There is wiggle room to tweak the acceptance criteria before its set into a sprint.
Step out your developer shoes and try being a user
#4 Become a UX persona
If you are a typical programmer this might be a hard one. In the UX world, when we design UI, we make up personas. In short, we imagine ourselves in a variety of situations, as people with specific needs or expectations of a website or app. This "walking a mile in their shoes" lets us find spots that we made easy for ourselves, but harder for an actual user.
Try to be an actual user of the site you are building, not a developer. Often times we as developers do things that make our lives easier. We pull in some 3rd party plugin, or we take a shortcut, or develop a component in such a way that we slap together a couple things and boom, bam, presto we are done. I'm sure you all had a situation where you really didn't want to do a task, because it was boring, or overly complicated, or you just had to do more coding for (in your opinion) a small return.
Well, I'm sorry to say, but it's better to be user focused in the long run. Yes, that means you should just do the long and boring task that will display a custom error notification depending on what the user did wrong, instead of a general "Error occurred". If you have a huge select box with hundreds of options, add a search bar to the select. Yes, that means you can't just use a native select tag, you need to go the extra mile to make the search filter happen. Adding that search filter will make users of the site appreciate that their time is not wasted scrolling endlessly till they reach the option they are looking for.
Alrighty! But what if things don't go quite so perfectly?
#5 You messed up now what?
So you messed up. Made the dumbest typo ever, deployed to live and shutdown the app for a couple minutes, hours? Your client is upset, counting the thousands of dollars he's lost during this time. Or maybe it wasn't even your code that spoiled the release?
Does this matter? Right now when everything is in flames? No. So don't go bounty hunting, trying to git blame the world. Find a solution. Even if it's a bit of silver duct tape to stop the problem on live while you work on a proper fix in the meantime. What's done is done, focus yourself on solving problems and preventing future issues instead of blaming those around you.
If it's your fault just step up and own it. "I made a mistake, I'm sorry, here's my solution". People usually show empathy if you admit to being wrong. Don't escalate a tense situation with name-calling and pointing fingers.
After all the dust has settled and emotions are low, open a dialog with your client, or your teammate who screwed up. Suggest ways to avoid such failures in the future. If it's not the first time this happened, try reaching higher up to team leaders, managers, CEO's.
These are my conclusions
In almost all the projects I've ever had I try to be proactive, and get involved. I befriend the client and closest workmates. This has proven to give easier communication with everyone. The client trusts me, know that I think ahead, and supply ideas when he can't get the perfect one. When something goes wrong, our emotions are not heightened, because we all understand that mistakes can be made, the thing to do is handle the situation, not escalate the problems. Its super easy to start blaming or looking for flaws in others.
This article was made in collaboration with Amsterdam Standard.
"TLDR; summed up in a short list"
1. The word "shoes" was used often. Don't be one sided, try and understand the other point of view and consider what is truly the best option for success.
2. Step up. If you have questions, or you have a better suggestion or if you broke something. Step up, take ownership, accept it, improve on it.
3. Step back. Take a look at the big picture. If you only sit in your little bubble, how can you make informed decisions. Obtain knowledge about your entire project, about the business model, about your client. Be involved.
4. Be your projects user. It's easy if you are making an e-commerce site, a little harder if you are making dashboards for fintech. But picture yourself using the app, notice things that have a flawed flow, or are hard to use, or could be improved with the next iteration.
5. You are a part of the team. So if you make a toxic environment, you'll have to live in it. Make smart relationships with coworkers and clients. Maintain a work/life balance in your team. If things escalate get assistance.