djstrickland, Author at SEQTEK - Development Delivered
Call us to get started at 918-493-7200

Breaking Into Tech

Matt Lemke

Matt Lemke

Full Stack Developer

Beginning my first role as a developer at SEQTEK was just like every other step in this journey, it started out very difficult. There is a curve to going from a learning environment to a real world environment just like any job. Though it was challenging, everyday I have learned something new. Whether it be from a co-worker, digging for solutions on the internet or just having my own breakthrough moments I have been able to soak it a years worth of education in just a short amount of time by being on the job. The people I am working with have made the transition into tech very easy by being helpful and informative anytime I need them. I couldn’t have asked for a better place to start and I am glad I made this career move, I am confident from this point on, I will be in tech for the remainder of my career. 

 

 

Breaking Into Tech

By Matt Lemke  |  Last updated:  Monday, January 10, 2022

I had become like the characters we see in movies, sitting in my office mindless and waiting for the end of the day. I would sit in meetings that went for hours just wondering why I was here. As soon as I got home from a vacation, my mind was on the next one. Though I once loved my career and my job, I knew that the time had passed and I was faced with a decision: to stay here because it is comfortable or find something new. The question is always “If I’m not doing this, what will I do?”. This question lingered in my mind for months, then the pandemic hit. As we were sitting at home watching and waiting to see what was going to happen, I realized this was the time to make a career shift.

 

I had always talked about getting involved in tech. Since I was a child in C.A.D. class, I have always marveled at what technology could do. When I graduated high school, a friend of mine who was a Computer Science major showed me a website he was building in C# and I thought it was the coolest thing I had ever seen. I had always wanted to learn to code, but something else always took priority. So I jumped on google and began researching how to become a “coder”. I’ll never forget the three questions I googled: “How to become a coder?”. This is when I quickly found out the different titles and types of developers, “how much do programmers make?”, and “do I have to be able to type fast to be a programmer?”.

 

One site that popped up multiple times in my research was Codecademy, so I hopped on there and started with their “HTML/CSS” course. I loved it and I could tell this was the next step for me. So I dug deeper on how to get myself ready for this career shift. I found two paths in my research: self-taught, and computer science degrees. I began searching for anyone who could give me advice and I found an old friend from high school who had a developer background, I messaged him and asked him for some of his time. I focused my questions on what the best ways to break into the industry are, that's when he started to tell me about Bootcamps.

 

He explained the Bootcamp route to me like this: “You can learn almost anything in tech on the internet, but you need to know enough of the basics to know what to ask If you don't know what a function is, you won’t know how to find the right content to learn what you need because Google can't give you an answer to a question you are not asking. So a Bootcamp will help provide a layer of the basics for you so you can learn the rest on your own. They are like a roadmap to know where to look, what to do and what questions to ask when you’re stuck. After the call, I found a six month Bootcamp at UT Austin that was perfect for me.

 

On top of my job, I spent thirty hours a week working on the Bootcamp, plus another fifteen hours building projects on my own to speed up my development. It was a steep learning curve, there is nothing easy about learning to code but I loved every second of it. Four months into the Bootcamp, I quit my job and spent at least thirty hours a week working on algorithms, problem-solving and personal projects for my portfolio on top of the other work in the course curriculum. This allowed me to be employer-ready before the Bootcamp ended and gave me the confidence to apply. Though the company wasn’t hiring an intern, I messaged a CEO via Linkedin and asked him for a chance to gain experience. We connected well and he gave me a 3 month paid internship before graduation. The internship set me up perfectly to get experience while working with a recruiter for a long-term landing spot.

 

A month before the internship ended my recruiter helped me find an amazing job as a full stack developer that was perfect for an entry-level position. Like I stated before, there is nothing easy about learning to code, so my advice to anyone who is wanting to learn is to: Start with HTML/ CSS and make sure you enjoy it. Then try a harder project via Codecademy or another website that will challenge you. If you’re still hooked, find a Bootcamp and take the concepts you are learning there, and dive deeper into them on your own. Build your portfolio, find a recruiter and put yourself out there.

 

Good Code vs. Bad Code

Managers and executives are becoming increasingly aware of the problem of “Bad Code.” A few relatable questions are: Why are the new features taking so long? Why are we dealing with so many customer issues? Why is the turnover in our IT development group so high? All of these issues can be attributed to bad code, but what is “Bad Code” exactly, and how is it affecting the business? Asking ten developers what bad code is might result in ten different responses. In order to understand how “Bad Code” is affecting a business, the terms “Bad Code” and “Good Code” must be accurately defined.

What’s the Difference? 

The difference between “Good Code” and “Bad Code” can be understood most easily in a comparison. Below is a comparison chart between good coding practices and bad coding.

good code vs bad code seqtek success
The compounding effects of each of these comparisons helps to understand why new features are taking so long, customers are dealing with continual issues, and stress in the IT department is causing low morale and possibly turnover.  In my view from a Software Engineering perspective, I have provided some information below to help understand the comparisons more effectively. 

Easily Understandable vs. Difficult to Follow

Code that is easily understandable allows developers to quickly and accurately make changes to the codebase in order to add new features and resolve customer issues. However, difficult-to-follow code has multiple problems. Bad code makes new features difficult to implement, customer issues are difficult to resolve, and onboarding new developers becomes a lengthy and difficult process.

Logically Separate vs. Inseparable Modules

Logically separated modules allow many developers to work on different aspects of a solution without interfering with each other. However, inseparable interdependent modules make it impossible for developers to make any changes without a comprehensive understanding of the application. This causes longer onboarding for new developers, decreased performance of the dev team in general, and developer dissatisfaction.

Testable vs Untestable Code

Testable code with unit and integration testing is vital to give developers confidence in adding or updating features. Untestable Code lengthens the development cycle by requiring extensive manual testing and regression testing for code change. Fragile tests are sometimes worse than no tests at all because they will require the developer to maintain multiple codebases without any discernible benefit. Tests that have to have extensive rewriting to facilitate any code or business logic change need to be refactored to test modules in a more robust way.

Descriptive vs Arbitrary Names

Descriptive naming conventions add to the readability and maintainability of the code. Arbitrary names cause confusion.  Idx, count, temp, buf, etc. All these names devoid of context are meaningless. A new developer will have the question of what are we indexing or counting? Temporary what or buffer for what?

Well-documented vs Poorly Documented Scripts

Well-documented means appropriate for the situation. If a class or module is very well named and has a clear control, flow documentation can be brief. If it is confusing, difficult or requires extensive domain knowledge, then documentation should reflect the complexity.

Documentation is never a replacement for good architecture and clear code. External APIs and interfaces must be thoroughly documented or there will be ongoing issues with code integration. Poor documentation may still be substantial but can be out of date or trying to cover for poorly designed code.

Up-to-date vs Depreciated External Packages

External packages are very necessary to avoid “reinventing the wheel” on every project. Keeping packages up-to-date and avoiding deprecated APIs is essential to successfully integrating external code into a project. Packages that are ending support or no longer being developed need to be replaced. Out-of-date or deprecated external dependencies will reduce the effectiveness of developers by causing them to spend inordinate amounts of time understanding and debugging code they did not write and for which they are not responsible.

Fixed vs. Flexible Architecture

The architecture of a project is something that does not spring into being fully formed. By necessity, the architecture needs to be flexible to changing business needs and requirements. Refactoring architecture to reduce complexity is essential whenever business logic significantly changes. Ignoring the need to update architecture because of the time required is taking on tech debt that will drown the development team and cause high turnover. No one wants to be responsible for risky architecture changes once the problem has gotten overwhelming.

After looking at some of the comparisons between good and bad code it is clear why good coding practices are so important. As technical debt grows from bad coding practices, feature development slows to a crawl, customer issues become more common and more difficult to resolve, and finding good talent to work on the codebase as well as retaining talent becomes completely unmanageable. Solving this problem is difficult without being able to explain why good coding practices are necessary for a healthy growing company. Pointing out the comparison between good and bad practices allows non-technical stakeholders to see why they must budget time and resources to maintain a good clean codebase, in order to keep new features easy to develop, manage customer satisfaction, and retain talented developers.

-Kenn Williamson, Senior Software Developer, SEQTEK

 

The pixel