And I can, I mean these aren't mythical skills that are reserved for the chosen few, they can be taught, they can be learned, and they can be perfected over time. How I approached this at the beginning was pretty straightforward, I dived in and made myself uncomfortable by taking on projects and tasks where I needed to interact with different team inside of the company. The best example I can think of that I'm currently working on is taking the lead of a user-facing web page where its sole purpose is to introduce the company to prospective candidates that we want to hire, hopefully capture their email, and even better get them to apply right then and there if they so choose.

Now I know what you're thinking, "Just build a landing page you dummy, what's so hard about that?", well you're right, but also wrong, let me explain. In order to get this page in the shape that it needs to be, it needs to look good, read well, work correctly, and give us back as much info as possible by way of event data to really get the most out of this page. The hard work that is going on behind this page make it imperative that I interact with our designers, product manager, marketing team, as well as fellow software engineers that help work on it.

When working on a project like this, stakeholders (parties with an interest in the project) need to be kept updated on status, current obstacles, and any relevant timelines for milestones. This has been one opportunity of hopefully many to really develop myself into at a solid communicator. Of course this one project wasn't going to turn me into a communications expert by any means, but it is a start. I've opened up communication channels with all stakeholders, created a central location so they could view the status along with any obstacles holding up progress, and I'm making sure sure to set a reminder semi weekly to update everyone on progress.

Projects evolve over time, everyone knows that, but keeping things manageable doesn't have to be hard, and proper communication is the catalyst that keeps everything moving. No communication, no progress.

Thanks for reading

P.S. I wrote a book! It's not just any book either, It’s the book I wish I would’ve had when I started my first software engineering job, seriously. Check it out!

(Cover Photo by Christina @ wocintechchat.com)

It's a concept known to most people, but practically has no value for the majority of people who are trying to make a living. Following your passion has to be one of the most misleading statements that permeate our culture today, mostly because of the context that it doesn't provide the right context to make a smart decision. If I had to rewrite that statement, it would say: "Follow your passion if it's marketable, pays well, and has longevity in the market. Let me break this down and you'll understand why it needs all those extra parts in the first place.

...It's Marketable

There are a ton of skills out there, like juggling multiple chainsaws, blowing up 5 balloons in a minute without passing out, eating 67 hotdogs in 15 minutes, but whatever skill you have, you need to ask yourself is it marketable? Is there a big enough pool of companies to hire for that skill, or people who'd like to use that skill in exchange for cold hard cash? If the answer is no, then I've got some bad news for you, keep that passion as your side gig in your free time, and look for that marketable skill to pay the bills.

...It Pays Well

Well duh, this is an obvious one right? Money really narrows down what meets at the intersection of passion and practicality. Unfortunately, money makes the world go 'round (well technically gravity does, but bear with me here), and you'll need to find your own way to make it spin. I try to really understand what skills are out there that pay well and most align with something I think I'd enjoy most, and get REALLY good at it. That's the key to finding the few skills that put you in the sweet spot of enjoyment and sustainability, it's a hard balance, but one very worthwhile to spend time searching for.

...Has Longevity in the Market

Think about the job or skill that you want to leverage into a job, is it going to still be relevant in 5 years? 10 years? 30? Now I'm not implying that you'd be doing the same thing for 30+ years, but I'd like for you to think about how needed that job or skill might be going forward. People like to think about tech jobs as practically immune from the passage of time as if that's an exception, but that's definitely not true. As technology progresses, so does the nature of the work, and one job that was growing rapidly the previous 10 years may plateau or even worse decline because of a new technology that makes something obsolete or automates an important aspect of the job entirely.

The tech industry isn't a special case here, longevity in the market has been synonymous with trade skills for decades even before tech became what it is today. Electricians, plumbers, general contractors, etc continue to stay in demand and will be for the foreseeable future, hell even funeral home services will FOREVER be in demand, right?

Following your passion often times means making a tradeoff, and that tradeoff has naturally been easier for those with privilege than those without, and it pains me to hear when people give that advice to just everyone because it's not very practical. Hopefully this post gave you a little perspective, or it completely pissed you off, either way I did my job.

Thanks for reading.

P.S. I wrote a book! It's not just any book either, It’s the book I wish I would’ve had when I started my first software engineering job, seriously. Check it out!

(Cover Photo by Kashawn Hernandez on Unsplash)

At the time of this writing that's how long I've been working at this startup, and it's honestly been an amazing experience. It was always one of the goals of my career to work at a place where everyone around me was so full of knowledge and had so much skill that I was bound to soak it up and become a better thinker, communicator, and software engineer. While all of that has happened, I've gained so much more that I never thought I would. I felt like it would be really beneficial to share some of the most important lessons I've learned so far, let's get started.

• User empathy is much more palpable when you stick close to them early on.

We really pride ourselves on communicating often with our customers, and making sure their thoughts and concerns are at the forefront of how we build our platform. We have internal meetings, external meetings with many customers, and have various other avenues of how get user feedback including a built in survey feature, and it's been great. Even though our platform is in its early stages still, it's wonderful to see how it has changed and been made better by just constantly listening to what the customer needs and aligning that with our mission and vision of who we are and what we want to bring to the world.

There is definitely a balance to strike between our vision and the customers' expectations, but the more you communicate with them, the better a balance can be kept.

• Personal responsibility is incredibly important when on a small and agile team.

When working on a smaller team that moves quickly to build and improve on existing systems, it's incredibly important to have a strong sense of personal responsibility within the company. I'm not guided by anyone during my day to day, and once I open my laptop I make it a point to make a plan for the day based on 3 questions:

1. What am I working on?
2. Who do I need to sync up with?
3. Do I owe anybody anything from yesterday/last week?

These three questions first thing in the morning sets a good path for the rest of my day with clear focus and intention. Take time to understand whether you're putting in the work to understand your day fully to where you have clarity on what needs to be done.

• Taking the initiative and focusing it helps more than hurts, there's always work to do.

If you're working at a startup that is growing fast with a great product fit, there's a LOT to do, and personally I absolutely love it. However, with fast growth can come that feeling of overwhelm, which can get messy if you're not focused. I spent a lot of time when I started trying to understand my role and what was more important vs what was less of a priority. This meant understanding our kanban board lingo (list of tickets and their status), our sprint planning schedule, staying aware of the bigger projects that we were working on, documentation that could help with various tools that we used, etc.

I set myself up on the right foundation by understanding all of that first, and then focusing my initiative on the things that really mattered, and it hasn't let me down yet!

• Get it right first, make it perfect later.

When you're trying to move quickly but also correctly, your code will almost never be perfect. I've learned multiple times over that, contrary to my personal need to make things perfect the first time, things just need to work and be fully tested the first time around. You can always come back around later to refactor to your liking.

What's really important to understand as a new engineer coming onto a small and fast moving team is that we tend to think that we need to make the least amount of mistakes for fear of making a bad impression, but everyone makes mistakes and learns from them to get better. It's a part of what we do, and there's no getting around that, ever!

• Get out of your comfort zone often, startups are THE best place to do that.

This has to be my favorite part of working at a startup, the ability to step outside of my comfort zone early and often. Being able to work across different parts of the team and not feel isolated on a single team allows me to see more than the code. I'm able to see how it actually affects the customer, and how perception of the platform affects the business development team, the design team, the founders, and everyone in between. I've gotten to work with so many people in HR, Finance, Legal, Design and other areas to really understand how our platform needs to behave and look.

Not being forced to only work with the engineers on my team (although I appreciate and care for you all if you're reading this!) allows me the opportunity to help build a platform that's accessible, easy to use, and beneficial for our end customers. It's so important to branch out as an engineer and understand the different parts of the company that you might never directly touch, because there's always something to learn that you could bring back into your own engineering world. Features, fixes, and complete re-works that benefit the customer are fueled by discussions across the organization, as we all have something important to offer as a team close to the product, whether you're directly contributing code or not.

As I continue working here with a great group of people in and out of my engineering team, I hope I can keep learning things about myself not only as an engineer, but as human being as well.

Thanks for reading.

P.S. I wrote a book! It's not just any book either, It’s the book I wish I would’ve had when I started my first software engineering job, seriously. Check it out!

(Cover Photo by Daria Nepriakhina on Unsplash)

Obviously there are almost infinite online courses on various subjects to take, but putting courses together in a way that cohesive is still a lot of work. The responsibility of creating that structure to learn rests on the student's shoulder, and that's where I think the student struggles most.

I'd like to give some advice on how I've created and navigated an independent learning curriculum for myself that allowed me to learn software engineering at a level where I've been able to work as a professional, and (in my opinion) be pretty successful at it.

• I deeply understood the path I wanted to be on and why.

Setting your sights on the path you want to go down and why is so important. You have to have focus as a driving factor to stay disciplined and achieve your goal of learning whatever it is you're setting out to learn. In my case, I knew I wanted to be a software engineer, so I knew that I had to learn about how the web worked internally, HTML, CSS, Javascript, SQL, and a server-side language that allowed me to create and interact with third-party API's.

Map out the topics that are critical to the end goal, and organize them according to what needs to be learned first, with the more complex topics positioned further along your plan. A helpful way to do this is think about each topic as a building block, and visually create a foundation of the basics, moving up into the more complex topics that build off of those fundamentals.

Knowing and understanding what you need to learn is obvious, but be honest with how much work that's going to be and commit to learning it all from the beginning or else you will very easily succumb to obstacles in your way. Constantly remind yourself why you're doing this, and what you need to focus on.

• I was realistic with how much time I needed to spend daily, weekly, and monthly.

Putting a time dimension on your learning is just as important as understanding what you need to learn. Just like honesty matters with what and why you want to learn something, it matters even more with how much time you can dedicate to it.

For me, I knew that my life changed a lot when I was first learning how to build software, so I knew I could only dedicate an hour a day, four days a week, so I stuck to that until I realized I could squeeze out another 30 minutes a day towards learning, so I bumped it up to an hour and a half a day Monday - Thursday and rested Friday - Sunday. This was a good routine for me until I got my first big boy job, that gave me a more predictable work schedule, which allowed me to dedicate much more time in the evenings to learning. I increased my time to three hours a day for four days a week, and quickly found out that was my limit, so I coasted there until I felt like I needed to pull back.

Life happens, establishing time commitments therefore need to be flexible, but not too flexible to the point where you're changing how much time you spend learning every day, try to re-calibrate every week, that way you set the expectation at the beginning of the week and fulfill your commitment, that will help keep you focused.

• I set hard monthly goals, but loose yearly goals.

Go big or go home, but don't be hard on yourself if you go home. Learning takes time, and setting goals can be tricky especially when you put a lot of emotion and expectation behind them, but they are necessary to give that much needed validation when we crush them.

I set my goals monthly because I knew that I needed to understand certain things about the web before I took on another subject, for instance I knew that I needed to understand what a DOM was before I even attempted to really work on understanding Javascript, and I needed to really understand HTML and Javascript if I was going to learn React. Knowing which building blocks were needed before others helped me understand what I needed to set my monthly goal at realistically.

My yearly goals were loose, a collection of my monthly goals wrapped up into a nice package, like creating a full stack application, or a command line application that automated something I did at work everyday. A yearly goal should serve to wrap up and include all or most of the hard monthly goals you set, and it doesn't have to be a large project, it just needs to be something that allows you to actively incorporate all or most of your monthly learning's.

I'm just going to go ahead and say it, your monthly goals matter more than the yearly ones, because the near term goals are the ones you can more clearly see and focus on, they shouldn't intimidate you as much as the yearly goals. The monthly goals also build habits and routines much better than yearly goals, proximity to the goal pushes you harder and motivates you a lot more.

This post is already getting pretty long, but I think these 3 points really helped me shape a learning curriculum for myself that allowed me to make meaningful progress to becoming a software engineer. And while the journey was long, it was incredibly worth it because I knew that I had crafted this plan and stuck to it while dealing with outside life occurrences. Remember, you don't have to have life lined up in a certain way to start, you just have to start and deal with life as it comes, good luck.

Thanks for reading

P.S. I wrote a book! It's not just any book either, It’s the book I wish I would’ve had when I started my first software engineering job, seriously. Check it out!

(Cover Photo by JESHOOTS.COM on Unsplash )

I mean seriously, who wants to relive their failures at the end of the day? I absolutely hated asking myself this question when I started doing it, because I only focused on how shortsighted I was about that thing, or how I missed something completely obvious, but it wasn't until a few times of doing this that I actually realized that this reflection wasn't to beat myself up, it was to build myself up, learn, and grow consistently in my career.

Asking yourself this question can seem off putting at first, but it's meant to nudge you to take the initiative, come out of your comfort zone and explore new learning pathways. It requires you to take a swing and a miss, but then actually learn from that miss and how you can correct for the next time at bat that hopefully results in a home run. Being honest with yourself at the end of the day this way also allows you to create goals and build a path for yourself where you can see growth more clearly and consistently, because if you're failing at something, you'll always have something to improve on.

We're all a work in progress, and shying away from that work is the last thing you should be doing if you'd like to grow in your field of expertise. No one is above making mistakes and learning from them, its how the best in their field got to where they are, no matter the discipline or industry. Being able to understand that the obstacles you run into are stepping stones on the way up to the mountain top of personal success, whatever that means for you, is so so important and a mindset shift that few will adopt for the long term.

Knowing where you're going is only half the battle, knowing where you've been and learning from those previous journeys is the other half, so please ask yourself, at least today, "What did I fail at today?".

Thanks for reading

P.S. I wrote a book! It's not just any book either, It’s the book I wish I would’ve had when I started my first software engineering job, seriously. Check it out!

(Cover Photo by the blowup on Unsplash)