Jump in the Deep End

“Always apply for a job even if you only meet half their requirements. No one can fit them all, you can learn.” – A lot of people

When I wrote about Mental Shifts in development, it also had made me think about how much I was learning and struggling at the project I was working on.

I had interviewed and accepted this job based on the skills that I had, and my ability to learn new things. I knew that it was going to be a big shift for me, going from a developer who was not really a developer to an actual developer. Despite the amount that I have learned in the last ~3.5 years, I still have a lot to absorb. All devs do, but after many, many years of learning something new for work (or fun), more experienced devs have a better handle on time it will take for them to learn a new language or framework.

I am not there yet.

The project I was jumping into is written with Angular. A framework I had only done half a tutorial on, and then Angular2 was already hanging over the project’s head. In addition, although neatly formatted, the comments didn’t really give much information to why X was implemented in Y way in many different cases.

It has been a headache and a half, but the amount of learning that I have done has been incredibly valuable. There is something to be said for learning by jumping in the deep end, and panicking before learning to swim.

Even though this has worked out, and a lot of growth in careers and jobs comes from someone saying to you, “Here, this needs to be done by Friday.” you should still be cautious to not get taken advantage of or overwhelmed. Noticing the signs for that is as hard as realizing that you’ve bitten off more than you can chew.

Every new job is a place for growth, as is every project. Don’t be afraid of the deep end. With that in mind, some notes:

Be able to say no. If you don’t know how, learn.

Be able to say, “when” (or ask for help). This is a moving target, you’ll learn as you go.

If you see someone you supervise struggling, do not tell them to give up and let someone else do it, ask them how they are feeling about the project. Offer them help.

We all get better when we work together!

Mental Shifts

As a relatively new developer (aka not coding since I could talk) when I step into a new code base that I have had no hand in writing, I try to write new code and solve problems the way the code was already written.

It was such a project that I stepped into with one of the larger projects I picked up when I started my new job. It wasn’t until I hit a massive wall that I realized that I was stuck in the code’s way of thinking, when I should have used recently accrued knowledge to

  • give the stakeholder what they want
  • update the functionality as per the spec
  • get the work done faster, instead of overcoming issue after issue (though every approach has problems to diagnose)

My eureka(!) moment came right at the end of a day that I had spent arguing with the code, getting close, but not quite to what I wanted. I left my desk to wander around the office and let the back of my head work on it while the front of my head dealt with other stuff. Or at least got distracted by the beautiful view out the back of the building.

So often when we are coming into a legacy code base (I use this loosely in reference to the code I was in) we either want to rip it apart or stick to the style at hand. We don’t allow ourselves an in-between. In this case, I had gotten too deep in the stick-to-the-style camp. Being able to get to that moment was pivotal in my growth as a developer and in the momentum of the project.

Within minutes I had it working the way I wanted to, all because I took a step back. Many experienced devs are like, “well, of course!” But I think this is a lesson everyone needs to learn for themselves, and some people (me) need to learn it over and over again.

Don’t get so focused on the trees you forget to look at the forest.

Select a Mess: Choosing a CMS

At the tail end of last year, I wrote about Ooooh, Shiny Syndrome and mentioned that we were in the process of selecting a Content Management System (CMS). It has been one way hell of a way for me to hit the ground running.

homer simpson running

The CMS that was used when I was hired is clunky, difficult, requires IT to be a part of content publishing, and we wanted to allow Marketing to have full control over content, while we work on the rest. Completely normal, and what a good CMS usually does. Umbraco was not that solution for us.

So, the first months of the new job has been meetings, demos, specs, sandboxes, and chaos. Not to mention the duct taping to keep the web properties running while we research and rebuild. And one case after another of OSS. Which, as I’ve mentioned, is a bitch to come down from.

We’ve finally settled on a package, and it was an adventure to be sure.

Some lessons learned:

Someone will inevitably have already chosen something as the end all be all and most likely not care about other packages. A version of OSS, if you will.

stubborn baby crying

There will be an amazing thing that blows you away and if you’re lucky, it will be that baller shiny I mentioned before.

Elaine from Seinfeld celebrating

Do due diligence for packages with partners that you already do business with. The execs will ask and you don’t want to be standing in the pitch meeting and have it cut short because you didn’t explore all options. Even if you end up not going with that partner, it will be appreciated that you checked anyway.

cat caught getting into drawer

Spin up sandboxes. I know that some of you reading are like, “well, duh.” You have more experience than someone else who might be reading this.

sandbox castle

Make sure to include the people who will be using this, and get their input. You as a dev may love one solution, but marketing or sales may find it difficult to use. You don’t want to blow $25,000+ of the company’s money that doesn’t solve your problems.

counting money

LISTEN TO YOUR GUT. If you have squeamish feelings about something, explore why and SPEAK UP. A gut feeling is great, but sometimes you’re going to have to explain why.

buffy the vampire slayer grossed out face

Be willing to argue about it. If everyone leaves it on the table, then you should end up with a great CMS, instead of a mess.

max capricorn doctor who