loading...
Cover image for RTFC: Why patience is a developer's best friend

RTFC: Why patience is a developer's best friend

cdvillard profile image Charles D. Villard Updated on ・4 min read

I'm typically not a patient person. It's a flaw I cop to a lot, and it's something I actively work on every day. I do my best not to be impatient with anyone or anything without a really good reason, but I'm terrible about being patient with myself as a developer. This character flaw of mine is one that's gotten my goat more than once, so I hope that, if you're about to embark on becoming a developer, that this helps you. And if you've been in the game a bit longer, I hope this endears you to your junior colleagues.

An impatient impasse.

The opus for this post came from a day working on a Vue.js component. It was my second production project using Vue, so I was excited to jump right in. After I got my developer environment set up, I looked for a smaller task to pick up just so I could get my feet wet with the other developers' code. What I settled on was a single file component for a modal. It would pull in data from a CMS to render a message depending on the URL. As someone who enjoys working with Vue and has worked with the library before, this seemed pretty simple to me.

I read through the user story, and started digging into the codebase. Once I got my bearings and put together a basic component, I wanted to be sure it would render to the page. I hit a mental block understanding how the components were being registered to the Vue app, so I asked one of my colleagues for a hand. This was a question that made sense to me because I had exhausted every possible idea I had, so I wasn't afraid to ask it. He pointed out that, while the core components were being compiled as a single file, many of the ancillary components like the modal I was working on were not, so they would need to be declared using a script tag in the markup.

So far, not so bad. I add the script tag and my component renders properly. Great, I think, now I can style it. It was then that I realized that there was already a modal component in the core library. Doubly great! I could simply re-use this as a child component and most of the work will be done. Pretty simple to me.

I began working on getting my component to play well with the modal. I skimmed through the code, trying to glean what made it tick, and tried something. I would then compile, refresh, and see that nothing worked. This went on for a while (read: hours). I could not figure out the issue. I would skim, try, and fail over and over. I would skim through the code, skim the docs, scrobble tutorials, but I still couldn't understand what I was doing. Eventually, I stepped away holding my head and thinking I don't know Vue nearly as well as I thought I did.

After a breather, I came back and looked at the modal's code one more time. This time, I read the code — not skimmed, read — to see what I was missing. Eventually, I came across it: an custom event to open the modal. Once I added that to my component, I breathed a sigh of relief.

A day in a developer's life

Let's get tangential for a second and take a look at what developers have to do on a daily basis. In a single day, a developer is likely to:

  • sit in on a scrum meeting to learn what everyone is working on,
  • read through a user story and gather information to discern tasks,
  • sift through documentation to find the best method to complete each of said tasks,
  • write and commit tests and/or solutions,
  • compile and most likely debug said tests and/or solutions,
  • ask around to see who can help with any issues,
  • submit pull requests to the main repo,
  • resolve issues from previous pull requests . . .

I'm going to stop there because I'm not trying to write an exhaustive or descriptive list, but that's more or less the working day of just a developer. I say "just a developer" because many developers wear more than one hat. Some developers may switch gears after lunch to handle developer relations, client relations, project management, scrum, or DevOps to name a few.

To the point of this post, then. With everything going on in a developer's day, it's extremely easy to become impatient, which can lead to a rough day of coding. As developers, we simply want to write Code That Just Works(tm). I've never seen this to be more true than for newer developers who have recently been hired. Suddenly, the pressure is on to show their developer chops, so when they can't find the answer on Stack Overflow or in the documents, asking questions becomes a game of "Shouldn't I Know That Already?" This begets a fear of asking, which begets a sense of panic when little code has been committed.

My biggest piece of advice to any newer developer is to actively practice patience. There's no rush to prove worth. There will be plenty of opportunity for that. For now, read the documentation. Ask all the scary, mean questions. Dig through the codebase. This is what will make you a better developer.

Posted on by:

cdvillard profile

Charles D. Villard

@cdvillard

Web developer with a passion for front-end development and keeping the web accessible and available to all. His downtime is likely spent cooking, raising his kids, or reading up on development trends.

Discussion

markdown guide