DEV Community: Kevin Path

Switching Teams!

Kevin Path — Sun, 13 Jan 2019 04:37:17 +0000

Late September of last year I decided to take the chance of posting out of the team and project I was currently working on! I've been on the project for two years and the colleagues I got to know well were also posting out of the team. I saw this opportunity to get myself back into the interview routine. Decided to stay internally with my current employer and try a different division/project/software stack. During my post out season I learned some valuable about: networking, projects, team culture.

Networking

An old college body within my employer informed me about a position open on his team who was seeking a developer senior developer on their team but that I should apply for the open position and see if I can snag the promotion. Seeing the opportunity that was made available I decided to share the open position with my fellow teammates and submit my own application for the promotion. Within couple of days I received an invite for round 1 of the interviews which covered some of the behavorial and experience questions and introduction to the project the position is for with the program manager and the projects technical lead. Within a few days following round 1, got an invite for round 2 with the project team manager and business manager where we had a fun time discussing podcasts and practicing my pitching skills. Turns out whithin a couple days I got the position my friend recommended to me but did not receive a promotion but a lateral move. This whole process really brought home how strong having a network has on ones career. The more people you have in your network the more opportunities you have available to you when needed.

Project Stack

My former team was developing a Create Read Update Delete(CRUD) RESTful API micro-services for a legacy Content Management System(CMS) using the Java Spring framework leveraging Pivotal Cloud Foundry for deploying the microservies to production and testing environments. Within the team I leanred how to deploy applications efficiently to production, how to leverage frameworks develop RESTful API, and developing/integrating pivotals gemfire caching services to improve content delivery speeds. None of the skills really transfer well over to my current project that requires me to develop analytics system in python on Amazon Web Services(AWS) Elastic MapReduce(EMR) clusters. But one thing I loved about transitioning to a new project is the fact I am attacking a new problem for a new set of clients. With the new problem comes a new mindset and a new approach which really brings me outside my comfort zone and puts me at a new angle for a problem and solution that was already in place.

Team Culture

Another impact of my transition was going from a big team to a small team which had a lot of advantages for my skills:

Pair programming with more developers to understand the project architecture more
Getting well acquainted with the team and understanding who was the point of contact for each part of the project

In Conclusion

Posting out of my first professional project was a fun experience and taught me alot. The amazing opportunities that come from networking with other people, the change of problem increased my approach to problem solving and increased my utility belt of tools I could use in my career, and finally the smaller team and the culture it created really made it feel like home as I switched from a huge team. I encourage everyone to take that leap to switch projects and try something new to see what lessons you can learn from jumping into something different.

Make sure to follow me on any of my provided social media handles and follow me as I continue with my 2019 resolution to have one posting a week where I share something interesting or lessons learned

Hello Internet

Kevin Path — Sat, 05 Jan 2019 18:13:22 +0000

Welcome to my space on the internet! This post is the first of many to come this year. One of my resoultions for the year of 2019 is to blog at least once a week. Feel free to provide me feedback on my posts or portfolio at any of the provided social media accounts provided on the navigation bar. As the first post of the current year I would like to use this post to kind of brain dump some of the ideas I had for the upcoming year!

Goals:

Finally start branding myself on the internet so can build my street creds :D
Give me a weekly motivation to step outside my comfort zone and learn something new
Figure out methods to engage with more people outside my current circle
Share my thoughts with the world
Ideas:
Recently switched projects within my current employer, talk about some of the lessons I have learned.
Share my current Workout Routine(one of the resoultions I have successfully achieved from last year).
Share some of the projects I'm currently working on to help improve my routines(code, lifestyle, etc.)
Build a engagement stream with users and figure out other weekly topics they would like to see posts about.

Well that's all I have for this post folks. Make sure you keep an eye out for weekly updates from me!

Webpage coming soon!

MVP(Minimum Viable Product)

Kevin Path — Thu, 26 Oct 2017 03:15:11 +0000

After listening to Ryan Hoover of Product Hunt and Courtland Allen of IndieHackers talk about their experiences on the Ycombinator podcast it really hit me both of them gained momentum for their products after testing the market with small simple products or minimum viable product(MVP).

Product Hunt was an email list in the beginning so really, I was forced, not being an engineer, to not spend weeks and weeks building something that may be something that people didn’t want. Instead, I was like, “Okay, well, what can I build and then what experience could I provide that would maybe validate or test whether people wanted this? I built this email list, sent it out...

Product hunt initially started its days as a mailing list, IndieHackers originated from creating a central location for people to share their own stories about the products they have built.Can't forget Ben started The Practical Dev as just a twitter account😋

How I could have benefited from MVP

Back in college, my roommate and I stumbled across multiple affordable deals local restaurants were offering to college students to attract more customers but was not marketed all that well.

We realized we could build a potential application that would allows to share and expand the deals campus wide. Once we got whiteboarding the idea was exhilarating because there literally was no other application or service like this offered at our campus. We had the prime idea, except we couldn't bring it to fruition cause we got carried away at waiting to build the "perfect" application with eye catching animation, material design, etc.

By the time the "perfect" application came around(spoiler alert: never happened). Another application, Hooked, came into scene and swooped the market.

Our could have been MVP: The minimum viable product for our product could have been simple as mailing list like product hunt were we collect student emails and forward them best deals on and/or off campus. This MVP could would have allowed us to test the market and see what kind of attractions we could have got and see how we could tailor it to our focused market.

Conclusion

To sum this all up, next time you have that brilliant idea forget about all those bells and whistles or which framework the cool kids are using and ask yourself the following two questions:

What is the core value your product is delivering?
What is the most simple and efficient way to deliver that value?

Once you answers those questions and tested your market then you know the direction you should be headed to make your product successful.

For the Love of Side Projects

Kevin Path — Tue, 16 May 2017 01:21:27 +0000

After I came across the article 4 frequent objections to side projects and my answer, I wanted to discuss my reasons and motivation for working on side projects.

It's my solution

There are tons of amazing work out there that solves a lot of problems but that does not mean it's the 100% right solution. Programming is about problem solving and the problems we attack are not always straightforward therefore I can work on a solution that is tailored to my interest and hopefully once I publish someone else might find it just as useful.

I get to play

Our industry is never slowing down therefore there are always new toys to play with. Side projects are a great playground for us because if we are excited about playing with some of these new languages/frameworks/libraries/software this is where we get to get our hands dirty. As stated earlier we can implement solutions for many problems in different ways which enables us to experiment more.

I learn a lot

My ability to apply better problem solving did not come from just my four years at college, it came from all those side projects I built up at hackathons. Every side project took me down a different rabbit hole of issues, therefore I had to actually count on myself to find a solution. Even though I resort to google and stackoverflow, I try to see how people on the internet solved some of the similar issues. Usually those solutions I find stick with me because I personally faced the problem.

A note to my younger self (and everyone who reads this)

Kevin Path — Thu, 20 Apr 2017 03:38:44 +0000

As the one-year mark approaches for my time in the programming industry as a junior developer, I would like to take the time to jot down four pieces of advice I would tell my younger self.

1. No one really knows what they are doing (most of the time)

Coming out of my 4 year computer engineering degree and transitioning into my first junior developer position was an exciting moment because all those dreadful days of all nighters were done and I could finally start doing things that I wanted to do. As I started planting my seeds in my first developer role, I got assigned my very first mentor who would show me the tricks of the trade. Even though he has been in the industry for about 5 years longer than me, I noticed he still gets stuck needs to use google and Stack Overflow to help him get out of those moments. To some, this is probably an obvious thing but not to my high school self, who thought the great programmers of today knew how to solve everything without seeking consultation online.

2. Read and write code

The only way to write better code is to read better code. At my job I found myself doing a lot of reading of the codebase to get a better understanding of the system I was working with and also following some of the rules they followed such as modularizing code, making it readable, how to comment. All these great skills build up over time and can be aided by reading other people's code and how they work.

3. Build and build and keep on building

When I was younger and researching about what programmers do, I would often come across a few languages like Java, C++, Ruby, or Objective-c. I would try to check out a book from the local library and try to read the novel from cover to cover hoping I would be an expert by the time I get to the end. Spoiler alert: never finished any of those books I started

The only way to get better at a language or framework or tool is to actually build something with it. It doesn't even have to be original either, you could find a basic project on the internet and try recreating it on your own without cheating. No matter how many books you read or blog posts you read you will never achieve that "expert" level without actually building projects and actually applying those techniques which you read about.

4. Failure is ðŸ—

There are a very low chance that your first project will be built successfully or make you a superstar in the computer industry. Everyone fails at one point in there life. The way I look at it is what learning opportunities did those failures bring to the light. Every time you build a project and run into an issue, you can ask your best friend Google, who will show you tons of possible solutions which help you jump to the next hurdle. The only way to claim your success is to face failure and learn from it.