DEV Community: David Neuman

Startup Life as a Junior Software Developer

David Neuman — Fri, 20 Mar 2020 13:07:24 +0000

Originally posted at david-neuman.com.

Entrepreneurship became more and more appealing to me after I decided to transition to a career in tech. I'm a frequent reader of Hacker News, and I listen to tons of podcasts about people sharing stories on scaling an early idea to a successful product or service. It helps that Montreal — the city where I currently reside — has a vibrant and growing startup ecosystem.

Despite my interest and access to startups, I figured that joining a startup as a junior software developer would be problematic from an experience standpoint. Initially, I wanted to join a larger company and gain valuable knowledge. Then, I thought, I could apply to a startup and have a greater impact.

My first job out of bootcamp was at a startup.

Since I recently took a new opportunity, I figured that it would be a good time to share what I've learned over the past 10 months working at a startup as a junior developer. It's worth mentioning that these points are not all encompassing — they simply reflect my own experience working at a startup (outside of the Bay Area) with little development experience.

You'll quickly contribute to features and have an impact on the product you're working on

Illustration by ouch.pics

At a startup, there's a greater chance that you'll contribute full-fledged features to the product that the team is building. And early on. Junior developers are often tasked with squashing bugs, writing tests, or making small adjustments to the application. While these are all important tasks, working on a new feature — especially as a junior — feels awesome. You get the impression that you're useful and having an impact on your team and the product.

The first job that I was tasked with was building a portal to host other client applications. From scratch. Talk about an early impact! Once the prototype for that was done, I joined another team working on one such client application. While it took some time to get into it, I was contributing features like my fellow teammates before I knew it.

It can be stressful working on full features as a new developer. But you learn a ton about how the application actually works, and being a primary contributor to building out an application feels great too.

You may write less tests

Source: Reddit

I realize that this point is controversial and very possibly biased. Nevertheless, I am assuming here that there are plenty of startups that choose to move quickly and churn out features, all the while — knowingly or unknowingly — failing to implement unit, integration, and/or end-to-end tests.

While members of my team wrote some back-end tests in C#, our front-end testing was lacking, to say the least. We replaced Angular's base testing frameworks with Jest and Cypress, but that's about it. It didn't help that we struggled to configure Cypress to work with the core drag-and-drop functionality in our application.

Most would argue that automated testing is an important component to building software. But you may find that at a small company that wants to move fast that it's overlooked until it's too late.

You'll be able to develop an early product mindset

Gergely Orosz has a great article on product-minded software engineers. He explains that developers with a product mindset "want to understand why decisions are made, how people use the product, and love to be involved in making product decisions".

Working at a startup as a junior developer gives you the opportunity to build a product mindset early on in your career. In a small team, you can ask a lot of questions about the product. Since you'll be working closely with a product owner, you can more easily contribute ideas on solving certain client pain points.

You'll gain full stack exposure

I Am Devloper

@iamdevloper

"full-stack" now means you can:

build front-ends
write back-ends
handle devops
start a podcast
curate a newsletter
crack an egg with one hand
animate a Pixar movie
dunk

08:53 AM - 05 Jun 2019

8026 28683

Do all the things!

The role of "full-stack" developer has seen its share of criticism. Yet Caleb Kaiser of AngelList argues that full-stack really means early-stage. When you join a startup as a junior developer, you'll gain exposure to many technologies on different parts of the stack.

While I did focus a lot on front-end development at Square Lab, here's a list of some the technologies we used:

Angular 6+ and, as a result, TypeScript.
.NET Core framework for C#.
GraphQL with Apollo. We also implemented real-time with GraphQL Subscriptions.
RabbitMQ for message queuing.
Redis as an in-memory data store.
Docker, Kubernetes, and ArgoCD for containerization and deployment.

Did I use, or even fully understand, all of these technologies? Absolutely not. But by virtue of working at a startup, I have become familiar with a diverse set of tools that contribute to the building and deployment of a modern application. I can do research on my own, or ask my colleagues how we use them to accomplish specific business or product objectives. In fact, exposure to many of these tools and technologies prompted me to purchase Andrei Neagoie's Complete Junior to Senior Web Developer Roadmap course on Udemy. My experience at work made me realize the importance of learning what these technologies aim to accomplish.

At a larger company, there's a greater chance you'll focus on one specific part of the stack. But at a startup, you'll be tasked with more work that involves different technologies. This can help accelerate your learning and grant you exposure to tools you may not otherwise have had by working at a more established company.

You'll need to figure out a lot on your own

A smaller team generally has less available resources to help you ramp up as a junior developer. What does that mean, exactly? Well, it likely means that you'll need to dive into the codebase without anyone to help you navigate your way around it.

As I briefly mentioned earlier, my first task on the job was to build the prototype of a new application. Its purpose would be to host other client applications within it as iframes — basically, a client portal. Truth be told, I was pushing code directly on the develop branch mostly without anyone reviewing my work. It was stressful and I think I would have benefited from more direct assistance. At the same time, I did learn a lot while building it.

The point here is that you may be thrown into an unfamiliar scenario without much direct mentorship. At a startup, you have the opportunity to learn a ton quickly. But you may need to get comfortable being uncomfortable for a while before you begin to ramp up.

You'll experience the ups and downs of working closely with a small group of people

By the very nature of working at a startup, you can build great relationships with a close group of people. I loved working with my team, and it's the thing I'll miss most about Square Lab. My teammates had great technical knowledge and were happy to answer any and all questions I had, which ranged from why we implemented a feature in a certain way to wrapping my head around a technical concept. Outside of my immediate squad, I had a blast at our frequent after-work gatherings or playing video games with my colleagues over lunch hour.

On the other hand, a small team also means that it becomes imperative that everyone plays nice. In larger companies, it's easier to avoid or ignore toxic and negative individuals. That's not quite the case at startups.

Even if you get along with everyone, it's worth mentioning that conflicts and disagreements between other employees spread quickly within a small organization. If it gets bad enough, the atmosphere at the office starts to deteriorate and the morale of the team spirals downward. All because some of your colleagues couldn't tolerate each another in a small enough team.

Hiring the right people that fit the startup's culture and values is thus incredibly important early on.

Is working at a startup as a junior developer a good idea?

Initially, I didn't think so. During my first few months I felt overwhelmed and, quite frankly, in over my head.

But as I got settled in with a new team and learned to lean on them for help, things started to improve. I learned an incredible amount in less than a year. I believe that working at a startup helped enable that.

As someone initially hesitant towards joining a startup as a junior developer, I hope that this post helps you get a feel for what the experience was like for me, and what it could be like for you.

Hello, World: A Welcome Message and My Fears of Launching a Blog

David Neuman — Sat, 04 Jan 2020 17:11:57 +0000

Originally posted at david-neuman.com

On January 3, 2019 I began writing at 200 Words a Day. Many of my early posts focused on my preparation for Lighthouse Labs' coding bootcamp. My goal was to become a better writer so that I could gain the confidence to launch my own blog.

One year later, on January 3, 2020, I am employed as a full stack web developer at a local startup and I'm launching a blog.

I'm not sure what it will become yet. My best guess is that the content will be a mix of:

What I have learned transitioning into a career in software development
My thoughts and ideas on the things I find interesting: technology, personal development, valuable lessons from books and podcasts, etc.
Small tutorials or "how-to's" related to the front-end development ecosystem

I hope you'll stay along for the ride and figure it out with me.

The Fear of Launching

All that being said, the decision to launch was not an easy one. I'm still not comfortable with making it public. But I have learned that you need to become comfortable with being uncomfortable. That's when you're pushing yourself outside of your comfort zone and where real growth happens.

So, what am I still afraid of? Mostly receiving feedback and writing unoriginal content.

Receiving Feedback

Here's what you would have seen if you visited my site prior to today:

Sorry, no visitors allowed!

My blog has been deployed to a Digital Ocean droplet and powered by Ghost for a couple of months now. Its design has been in development for even longer - originally I had a Gatsby site and was planning to deploy it to Netlify - and I may change it again in the future. The blogs of both Gergely Orosz and Steph Smith served as inspirations for using Ghost as a CMS, as well as for the excellent content. I had written a few articles but I wasn't entirely satisfied with how they came out.

The point is that I was afraid to expose myself publicly. If I don't launch my blog today, I will inevitably come up with a plethora of excuses for myself justifying additional work before it's ready. I may not have many posts lined up. The design may be subject to change. I might not even be satisfied with what I wrote for myself on my 'About' page.

But it doesn't matter. Learning in public is about putting yourself out there for feedback and keeping yourself accountable. As a writer at 200 Words a Day, I knew that each post would potentially be seen by another community member. And even if my post received no comments, that didn't mean no one read it. It was this accountability and possibility of feedback that kept me going.

And if no one reads my content? Who cares? William Zinsser, author of On Writing Well, wrote that you should be writing for no one but yourself. If you write for yourself and enjoy the process then you may just entertain others in the process.

Better to write for yourself and have no public, than to write for the public and have no self. - Cyril Connolly, New Statesman, February 25, 1933

Unoriginal Content

Will anything I write here be truly original? Probably not. But there's no way that I should let that become an impediment to writing.

For several years I wrote most of the music for my old band. I was theoretically writing "original" songs, but to say that these songs were truly original would be a blatant lie. My songs were so heavily inspired by other artists that the pre-production name of a track was often a play on words of that artist's name.

Illustration by Ouch.pics

This is Austin Kleon's main takeaway in Steal Like an Artist. The best ideas are "stolen" from other places and combined together to make something of your own. I would listen to tracks from several bands and combine ideas from different sections into a new song. I can still go back to our old songs and tell you which parts were inspired by specific bands.

Alexey Guzey also explains that unoriginal writing is useful because it "helps in the process of discovery and in the process of supporting underappreciated ideas". See all of the links in this post? Someone might read this and discover one of them for the first time. Or they might have heard about one of the ideas before and this post finally convinced them that it's something worth remembering.

Looking Ahead

If you like what you're reading, I hope you'll stick around for whatever else I decide to write about. I'm only just getting started - my hope is that it's mostly up and to the right from here.

I'm grateful for the 200 Words a Day community - especially its creator, Baz - for helping me gain the confidence to finally launch this thing. While I stopped writing there to focus on my blog, it helped me build a writing habit. The community there is fantastic. If you're looking to get better at writing I would highly encourage you to check it out.

I'd also like to thank Shawn Wang, Jonathan Borichevskiy, Steph Smith, Gergely Orosz, Alexey Guzey, and quite possibly many others that I'm forgetting about for inspiration.

And thank you, the reader, for taking the time to read through my first post.

What Type of Music Do You Listen to While Coding?

David Neuman — Wed, 27 Feb 2019 03:23:52 +0000

This fascinating article explains that those not prone to boredom generally performed intellectual tasks better while listening to complex music as opposed to simple or no music, while boredom prone individuals performed better with simple or no music at all. Definitely worth a read if you're interested in the impact music plays during periods of focus.

It got me wondering about what kinds of music people prefer while they code. Personally, I tend to prefer electronic, vocal-free music, but I can also surprisingly listen to heavy metal and still stay focused.

What do you listen to while coding, if anything at all, and why?

A Beginner Programmer's Approach to Problem-Solving

David Neuman — Thu, 21 Feb 2019 19:07:20 +0000

I wanted to share some advice my far-more-experienced computer science friend had to offer me in regards to approaching problem-solving programmatically. Hopefully you find it just as helpful as I did!

As a beginner developer faced with introductory problems that need to be solved, you may find yourself thinking immediately how you could implement your code to come up with a solution. For example, in the preparation modules for my upcoming Bootcamp, I needed to solve the classic "fizzbuzz" problem. If you don't know about it, you can find an example of it here.

Your initial reaction might be to think about how you could implement a function that meets all of the requirements. Do I use what I've learned about loops? I know there are scenarios here...how do I implement the conditionals into my code?

While these are valid questions you may ask yourself, here is the important takeaway: take some time to think about the problem without coding in mind. Reflect on the broader implications of the problem instead of diving right into coding away a solution. Think of it as developing a plan before you take action. Doing so will help you establish a framework for attacking the problem. In the case of the "fizzbuzz" problem, you might think this is a little overkill (I did, anyways). But I know that my friend has employed this method in stressful algorithm interview questions to great success.

I know this may be common knowledge for many of you, but I found this advice to be very valuable as a beginner developer. Hopefully, you do too.

Introducing Myself

David Neuman — Fri, 15 Feb 2019 14:26:46 +0000

Hello, Dev community!

I discovered this community just yesterday after listening to the most recent episode of the Product Hunt podcast featuring Ben Halpern. This seems like a great place to link up with other developers and aspiring developers such as myself. I'm about to begin a 10-week journey in a web development bootcamp in my home city to transition from the finance industry. I hope to write some posts here about my transition, learn from experienced members of the community and eventually give back by helping others out myself!

If you have a list/link with some good beginner resources or posts I can read I would greatly appreciate it. Looking forward to contribute to the site meaningfully in the future!

According to Ben, this is what I need to conclude my post with if I have nothing else to say...