How to Stand Out as a Programmer Without a Degree

How to Stand Out as a Programmer Without a Degree

Because being an engineer is so much more than just data structures and algorithms

My friend’s husband is a full-stack developer who has been working from home recently. She’s astonished at how different his work is than she imagined. Instead of coding all day, he spends his time on conference calls and Slack.

This made me consider the misconceptions about programmers’ work and what makes an accomplished developer. Writing code is an essential part of the job, but there is so much more to it.

Even if you don’t have an IT degree, you can thrive in this field. Here are some ways you can leverage skills from other areas to become a better programmer.

Image for post

Photo by Headway on Unsplash

The Secret is Communication

Programming is a team sport. You’re are not working in a vacuum. You’re working in a space full of people — other developers, managers, clients. It’s a massive advantage if you can communicate efficiently, clearly, and politely. If you’ve acquired that skill earlier in your career or education, it may prove a huge advantage.

Working alongside developers

You may believe communication with fellow developers is easiest. After all, you use similar jargon, may share attitudes, priorities, and interests. But it’s trickier than you may imagine.

I once worked with a senior developer who frequently seemed to ignore my questions and remarks. He just kept on coding as if I wasn’t even there. I would stand there disoriented, unsure if I should repeat the question, wait, or just leave him be. After a minute or two (or five), he would respond, always on the subject, and provide useful guidance.

It turned out that he heard me but answered after he finished the task at hand. He wasn’t unfriendly or unhelpful, just needed to take his time to respond. I could get angry waiting, but fortunately, I realized how to work with him.

Soft skills are also crucial when you’re receiving or giving feedback. It doesn’t matter on which side you are now — you have to treat feedback as a learning opportunity. Being polite and considerate is a must. You’ll have more friends if you don’t take feedback too personally and are able to also give it — with empathy.

Devote some time to get to know people you work with, their habits, and their communication styles. You’ll work a lot faster if you know who to ask for help and how to do it.

Communication with managers and clients

If you can’t get along with managers and clients, you won’t be a great developer. Programmers have their language and so do the business people. You have to remember that not everyone has your expertise, and often you need to explain complex topics in simple terms.

Developers who can connect those business and programming departments are crucial for the product’s success. By acting as a bridge you can not only make more friends but also accelerate your team’s work.

Countless potentially significant projects failed due to miscommunication. Don’t let that happen to yours — experience in another business may be critical in developing your company and your programming career.

Image for post

Photo by Dan Counsell on Unsplash

Writers are the Best Students

In programming, especially front end development, the landscape is changing rapidly. You need to learn constantly not to be left behind. The best programmers tend to be the best learners. And what’s a better way to learn than to write?

If you wrote a lot in college or your previous job, you’re already ahead of your peers. Writing requires critical thinking and organizing your knowledge. You’ll be amazed at how swiftly you learn when you explain a subject in writing.

By writing, I don’t mean taking notes. Notes are a useful learning tool, but you’ll grow faster if you try to explain programming concepts and techniques to others. So try creating a blog or other type of course for fellow developers.

Not starting a blog when I was a junior developer is my greatest regret. I could have accelerated my education and helped others.

Are you experienced enough to write a blog?

I know what you’re thinking: “I’m not experienced enough to teach anyone anything. Who would ever read what I wrote?”. I’m sorry, but you’re wrong.

You know something about coding, and what’s even better, you’re not an expert. Experts often know too much to help beginners effectively. They forgot what was difficult for them a decade ago, assume readers have vast knowledge, etc. As a beginner with some experience, you’re in a position to help others.

And what will happen if no one reads your blog? Nothing. But the knowledge you gained in the process will stay with you.

To write a blog post, you need to think the topic through, explain in simple terms, and structure your mental models. Often you believe you understand the subject, then, when you start writing, you realize that’s not the case. You need to clarify and enrich your understanding. By the time you finish the article, you’ll grasp the subject.

Whether anyone actually reads your blog is not relevant. What’s relevant is your growth.

Image for post

Photo by Austin Distel on Unsplash

Understand the Business Behind the Code

Programming is not the contest for the best code. It’s about solving real problems and creating actual products. You need to be wary of the project’s requirements and also what value it gives to the user. If you’ve got business experience, you can leverage that to your advantage.

Choosing the right tool for a job

The product’s business goals determine countless decisions. Part of your job is recommending appropriate solutions to solve client’s problems.

A startup with a budget for a few months that wants to test its idea faces different challenges than a bank that needs software for the next decade. You have to take that into account when speaking with the client.

Understanding the potential client’s priorities makes a difference between getting a project and being rejected. Both managers and clients covet developers aware of business goals and limitations.

Focusing on crucial parts

It doesn’t matter how good your code is if you misunderstood the requirements. Being productive is different from being busy and hardworking. You are productive if you’re doing the things you need to do.

Developers waste countless hours on non-essential features. Spend days on improving the performance of code that’s already performant enough. We like to repeat that programming is all about the tradeoffs. That’s correct, but we’re all biased, and our preferred tradeoffs can be different from our client’s.

Programmers tend to go with clean, elegant solutions — performant, maintainable, and expendable code. That’s often the right choice. But not if you’re creating an app with a one-day lifespan. Your code is not the product. If the app doesn’t solve the problem the client won’t care if the codebase is brilliant.

Your code is not the product.

Think about it from the client’s perspective. Imagine your team is responsible for creating the conference app front end — attendees will use it to review speakers and send their feedback. The app will be used only once — for the conference. It’s a simple project with a weak deadline.

Which developer does the client prefer? The one who took four days to write maintainable code responsible for searching the speaker and a single day for other tasks, or the one who talked with the client about the priorities and focused on an intuitive user interface?

Developers who understand business get promoted

Understanding the product will help you to become a better programmer. It’s also a highway to higher positions.

Coding is a part of the job. The higher your position, the less time you’ll spend coding.

You can achieve only so much if you focus solely on coding. To be promoted to lead or architect position, you need to get a deep understanding of the product — it’s current state and direction. You need to plan and be able to prioritize.

Developers who understand business are valuable on every level, but in top positions, they make the difference between success and failure.

Did you find this article valuable?

Support Szymon Adamiak by becoming a sponsor. Any amount is appreciated!