I have finally graduated from FlatIron School’s Full-Stack Software Engineering Course!
It feels so good to finally be able to say it!
I am quite proud of my achievments in software engineering so far, and I am excited to get out into the field. I knew that I completed the course, and thus am qualified for a software engineering position, but after graduation, I was eager for the chance to really dig in and prove to myself that I really can succeed in this industry.
Little did I know, that chance was coming sooner than I would expect.
I reconnected with a friend from college on LinkedIn, and I soon learned that he owned his own company. Chek Creative partners with their clients to provide comprehensive, long term solutions, turning their ideas into fully-flourished assests via many avenues, not limited to branding, web design, app development, and marketing.
After catching up with Joe Chekanoff, founder of Chek Creative, I was invited to shadow him and his team as they began creating a new feature for one of their clients. While I have had experience with React from FlatIron, the backend of the application is built with Node.js, which I had never worked with before, so I was excited to check it out!
I shadowed Joe as he worked with the backend, as well as their Lead Developer as he manipulated the frontend. It was illuminating to see code being translated into a real, live application!
Soon after the second shadowing, Joe invited me to come on as a freelancer to develop a solution for a new feature in the frontend.
I was thrilled! So much of the opportunity was brand new: working on an existing codebase, crafting solutions from a pre-existing design, and simply working on an application with a team are all things I had not done before. Here is what I’ve learned so far:
Take a look at the codebase
Before I started clocking in work, I took some time to really look over the pre-existing codebase. It was quite extensive, and I wanted to make sure I could target which components I was modifying, and how I wanted to do it. I only scratched the surface during the shadowing sessions, and this gave me a chance to become comfortable with how the existing code worked, which helped to formulate my own additions.
For example, I had not worked much with Bootstrap CSS classes, but the application used them extensively. So, in preparing to add code to my feature, I researched and used the appropriate Bootstrap CSS classes, keeping the codebase consistent.
If you don’t know something… ask!
When I first started to build the assigned feature, I knew the basics of how I wanted to implement it. There was, however, a pre-existing design for the application, with imported font-families, a specific color palette, and delinated margins. Implementing changes according to the design was very important for any newly added feature, but there were often specifics for this implementation, be it syntax or specific values or arguments, that I did not know how to use.
When I first came across one of these specifics, I was timid and felt like I would be looked-down on if I asked any questions, so I instead searched the codebase in places where the answers could not be found. This was wasting precious time, and I quickly learned that it is almost always better to simply ask about it.
In this setting, I was working on a team, where success was reliant on everyone. If there was an issue with the API, Joe would hop in and fix it. If I had any questions, the other team members were always happy to answer them when they could. This effective communication directly resulted in saving time and producing results.
Getting the job done
In the FlatIron course, I was completely self-paced; I set my own deadlines, and if (when!) they were not met, they could be moved back to suit my needs. I could (and did) spend way too much time designing my database, and cleaning my code to be as DRY and robust as possible with no real time constraint.
This, I soon learned, was a luxury.
In a real world setting, clients have deadlines. They want to ship out their product by a certain date, and as a developer, it is your job to deliver promised features by that time. Sometimes the deadline can be malleable, but that is never something to bank on.
While I could sometimes brainstorm of marginally more efficient solutions, I found that whenever I found a good solution, it was often satisfactory for the project.
I am not implying that quality should be sacrificed.
What I am saying is that once a solid solution exists, there is not a need to find the absolute best solution there ever was.
In No-Deadline-La-La-Land, I could spend all day just playing with fonts, or reducing just one function’s bigO time complexity. In a professional setting, however, finding a solid, working solution is often a higher priority than finding the Greatest Solution.
Conclusion
I absolutely love working with the team at Chek Creative. They have great integrity for what they do, and I am excited to continue collaborating with them. They gave me my first opportunity to code real-world solutions on a live application, giving me the confidence I need in carrying out my search for a full-time position.