I have been a frontend web developer for a long time. I know that territory pretty well, and JavaScript is by far my best language. It was also the first one I learned in any depth. I have done some ad hoc backend work in the past mainly just for my own projects, and they were usually very thin. There have been times when I wrote entire PHP/MySQL type backends, but I was not good at that. I did not enjoy working in PHP for damn sure. That language sucks (or at least it did back then).
As of Monday, Aug 12, I started a new role at Kemper, which is an insurance company. I did not totally understand the role when I took it, but I understood we would be using the Java language, and I knew that it wasn’t frontend. Something else. Backend, or maybe some kind of middleware.
Don’t misunderstand me. I love frontend. But a combination of values judgments and opportunity events led me to take a position doing backend this time. Perhaps most important was that I just had a difficult time finding another job that was only frontend, like the last one I had at LendingTree. A lot of job postings want a “full stack” developer, some mythical person who knows the entire tech stack of making a website. There’s no such person at all, but as somebody with no backend experience, there’s no way I could even pretend to be that.
Seriously, if you tell me that you are a “full stack developer”, I will nod politely. But internally I’m wondering which, if any, element of the stack you actually know well. For me, that’s frontend. I know frontend well, so that’s the best way to describe me right now. I’m a frontend engineer who just took a job as a junior backend developer for the first time.
This job was not my only option though, and another factor in my decision was that I want to learn backend. I want to learn Java, and Spring, and Maven, and maybe even some SQL, a little Jenkins—that entire cluster of skills relevant to creating a robust web backend that actually does something interesting apart from just serving a single page application. You might be thinking, aha, you are studying to become a “full stack” developer. Meanwhile I am thinking that, even as I write this, frontend keeps moving forward, and since I’m doing backend full time now I am not staying abreast of frontend anymore—not like I was. Every day here I become less a frontend engineer and more a backend engineer.
All of that is fine. It’s what I signed on to do. Those were my reasons, and I stand by them. But there are costs to bear in mind. I gain backend skill by letting my frontend skill get ever more dusty and dated. I’ll fight against that, but one can only do so little in one’s spare time outside a full time job.
You will note that I didn’t say anything about money or pay at all. I am actually earning 10k less in the new job than I did at my last full time job. That’s just not something I care about so much right now. I see this as an important and valuable career move that will give me a lasting strategic advantage for the future. An extra 10k in earnings for the year is a small thing compared with that strategic advantage, in my opinion.
As of today, I have only finished one week of work. I was not even assigned a task yet other than onboarding, but I want to share some initial thoughts on the transition. By the way, obviously my thoughts are my own, and I don’t speak for Kemper.
I realized pretty quickly while onboarding here that my job will be to help build and maintain an endpoint very similar to the ones our website consumed when I was at LendingTree. LendingTree is basically a comparison shopper for loans. When you fill out a loan request on LendingTree, it responds with actual quotes from banks and other lending agencies in real time. On the backend, LendingTree communicates with APIs at those companies, passes the application data, receives a response, and shares that with the user on the LendingTree website.
Similarly, there are comparison shoppers for insurance. At Kemper, I will be working on the code that talks to those comparison shoppers. So, when a customer goes to an independent insurance agent to buy insurance, together they might go to ITC TurboRater to enter the applicants information and get quotes from various companies. At Kemper, we are an insurance provider, so we have an API that those comparison shoppers can talk to. TurboRater sends us applicant information, and our real-time rater application responds with a quote. It happens in real time, fetches a lot of data, processes it according to business rules, and sends the quote back to TurboRater. That real-time rater backend API is exactly what I am working on here at Kemper. It’s exactly the kind of thing LendingTree consumes in the same way that TurboRater consumes this endpoint. The difference is just the product. LendingTree is better known for mortgages and other loans. We do insurance.
Getting some backend experience did not have to be Java, but to get this job I’m sure it helped that I know some Java. I’m Oracle certified in Java, which means surprisingly little. It for-sure does not mean I’m up-to-date or that I know how to actually build an enterprise application in Java. I hope to learn those things, but when I started here I only knew academic stuff, how to make tiny, self-contained Java applications that do little more than “hello world”. I don’t know Spring, and that’s going to be essential. There are a lot of new technologies for me to learn, and I love it.
In fact, I have a few recommendations on some techniques for handling the firehose of data coming at you as a junior developer. I’ll probably write more on that topic later, but for now I just want to mention a few things.
- I strongly recommend you buy a decent, archival paper notebook (I prefer un-lined, blank paper), and an archival quality pen, and then start bullet journaling. Just Google it. There’s plenty of stuff to explain what that even means.
- Maintain daily records of your activities. Some companies will make you fill out explicit timesheets accounting for your time even though you are not hourly. It’s an accounting thing. Even if nobody asks for timesheets, it’s still a good thing to have a paper trail demonstrating that you’ve been working, and on what. These logs go in the bullet journal.
- Take notes about the stuff you’re learning. I don’t recommend putting these notes directly in your bullet journal, but I do recommend using analog notebooks. It’s just easier to add sketches, mind maps, to connect information any way you want. Right now I’m using a system of just writing things ad hoc on printer paper and filing them for later processing, but I do plan to get a good quality notebook and routinely go back over these individual note pages and make more cohesive notes in the notebook. For thing kind of thing, I always recommend good quality, sewn notebooks with no lines or grid or anything
- Use the Chrome Reading List extension (https://chrome.google.com/webstore/detail/reading-list/lloccabjgblebdmncjndmiibianflabo?hl=en) or something similar for your own favorite browser. It’s different from bookmarks. Bookmarks will just stay there forever, but a reading list is really a queue of stuff you want to read and then check off the list, and that change in attitude helps when doing a lot of online study of tutorials and such.
- Get a good tab manager for your browser also. On Chrome I like Tabli (https://chrome.google.com/webstore/detail/tabli/igeehkedfibbnhbfponhjjplpkeomghi?hl=en).
And if you are a junior developer like me and you’re pretty new to the job, try to learn as much as you can. Jobs don’t always last forever, and it’s the experience and knowledge you gain on this job that will help you get the next one. It’s often very easy to tell when somebody really knows what he’s talking about in tech because complicated ideas and jargon and explanations just flow out of him or her freely and confidently in conversation. It’s easy to see that in someone—or not. Knowing stuff really does matter, not just years of experience.
I’m definitely going to keep writing more about the new job, so subscribe or bookmark me if that interests you. Also I’ve already written quite a few tweets about it on Twitter. Follow me on Twitter. I’m @adamfgcross, and that’s where I do most of my social media stuff. Twitter is also a great way to get updates on when I write these long-form blog posts here.
Thanks for reading. If you want to comment or ask me questions, I encourage you to contact me on Twitter (@adamfgcross). I’m totally open to talking with new people.
adamcross.blog 