Here’s What I Learned in My 10 Years as a Software Developer

I’ve been a software developer for 10 years now. I can say that it’s been one of the best things that happened to me. It’s one of those things that can give you that feeling of accomplishment, and the feeling of fulfillment that you are learning something new regularly.

There are times when I just hate doing what I do, especially when there are certain problems that require solutions that I don’t know yet. But a good developer will take it as a challenge, power through the obstacles, and deliver a working solution that is carefully curated and implemented to deliver functionality that could stand the test of time…

…or just copy a solution in StackOverflow, paste it in the IDE, run the build, and pray that nothing will break.

I still have a lot to learn. I need to do a lot of things. I need to work on my certifications. But I believe 10 years is long enough to learn a few things that are not usually taught in schools. 10 years is more than enough to grow as a professional that can provide solid solutions to challenging problems. 10 years is not bad of a number to share some valuable experiences with the next generation of software developers.

So if you would consider, I humbly present a list of things that I learned from my experience as a software developer. I hope this could help you, the person reading this, to be a better developer and hopefully learn from my observations, my choices, and my shortcomings. Also, I’ll include a few of the things my friends and role models shared with me that made me the software developer that I am today.

Incognito Mode is your friend.

For web development, there are times when you’ve done some changes to your Javascript code, and for whatever reason, no matter how many times you do a hard refresh to clear the cache, the JS code just doesn’t reflect the changes you did. When that happens, you have three options: you clear the entire cache and maybe everything else for good measure, you append a string to the Javascript file URL, or you open Incognito Mode and do your tests there.

In my opinion, using Incognito Mode is a quicker way to go around this since all you need to do is to open an Incognito Mode tab, open your test site’s URL, and you’re done. It’s not the best solution around. But for quick tests and verification, it’s the one I prefer.

The client does not care how you do your job as long as you get it done.

I like what our fellow Jordan Hall has said in one of his tweets:

Remember: Your clients will not give a crap if you squeezed your code into one line.

Placing functionality and maintainability over optimisation is critical. 👍

— Jordan Hall 💻 (@DivineOmega) February 11, 2021

Remember: Your clients will not give a crap if you squeezed your code into one line. Placing functionality and maintainability over optimisation is critical.

Unless your boss or client is really particular about the intricacies of your project, they won’t care if you use ABCs as your variables or use goto’s to end your loop.  Your boss/client is more likely focused on adding more value to the project. As long as you’re getting the job done, they most likely won’t give a crap about architecture or how you send the data from the API to the main application.

Another thing is the compiler/script engine/CLI/<insert processing engine here> works in mysterious ways, and most of the time, it won’t care how you’ve written the code. Sometimes long code provides more efficient processes, while shorter code at times is too short and simple that there might be a couple of things under the hood that we don’t know about. Therefore, shorter does not always mean more efficient.

Also, we’re living at a time where a few excess clock cycles won’t matter for the most part. Sure, certain processes heavily depend on the efficiency of the code. But most of the processes that we make these days are not very demanding when it comes to computing resources.

So if your boss/client does not care how you do your job, shorter does not mean better, and a few clock cycles in excess won’t make a difference, maybe we can make the code work better for us developers? We can make more functional, more readable code that makes sense when we see it the first time. Adding a few more lines of code in exchange for better maintainability is always a good trade-off.

Optimization should not be at the top of your list. A properly maintained code will always be better than an optimized mess.

Take the cheesy acronyms, remember them by heart.

DRY, KISS, SOLID, and YAGNI are just a few of the acronyms that sound so cliché, they just get way past our heads and we tend to not even bother about them. But we hear them way too often for a reason: they’re good tips to live by.

As software developers, we got a lot on our plate. We basically need to interpret a business concept and turn it into something actual people can interact with. It’s like building a house and we’re carpenters (except carpenters get stronger as they work, while we might be losing muscle mass by doing our work). We got a lot of stuff to figure out and a lot of things to do. These cheesy acronyms are there to remind us that we need to keep things efficient and focus on the things that matter.

One does not simply copy-paste code.

StackOverflow, CodeProject, and other developer forums are a godsend. They can really help you when you’re trying to fix an issue in the code or you’re trying to remember that functionality that you’ve read from a developer blog before, thought it was cool, then proceed to forget about it for a couple of years until the time you finally need to implement the same functionality. They really make the job quicker and easier.
But come on, people. We can’t just copy and paste code and not understand what’s in there. Make sure that it fits the purpose, it does the job to a tee, and it doesn’t do anything unnecessary. If we’re going to copy someone’s code, at least make sure that it won’t bite us in the ass in the future.

Speaking of something biting us in the ass…

Focus on good design today so it won’t bite you in the ass in the future.

I get it that we have our deadlines. I also get it that we want to get a project done as quickly as possible. But making a quick job out of a project is not always the best approach. We need to focus on producing a project with source code so good that even if we go back to it after a couple of years, we can still easily understand what’s happening. Maybe it’s hard, maybe it’s too ideal. But the more we focus on simplifying the hard stuff now, the easier it gets for us to work on it in the future.

And don’t even get me started with projects that you know you’d not maintain in the future. It’s not like you’re not going to work on this project ever again, you would just do whatever you want and give the future developer a hard time. Don’t do the things you don’t want to experience to other people.

It’s good to be uncertain about things.

I will never forget the time one of our managers told me this:

You should be happy when you’re uncertain about something. If you don’t feel any of that, then you should be worried.

The feeling of uncertainty is one of those things that I don’t want to feel. I’m a person who prefers to know what’s happening. I tend to overthink and uncertainty is like jet fuel to the raging dumpster fire that is my brain.

But uncertainty can be good sometimes. It either means I’m doing something new, I’m doing something I already know but haven’t tried yet, or it can be a chance to redeem myself from something I could’ve done better.

Uncertainty means getting out of the comfort zone. If you don’t feel it, that probably means you need something more challenging.

Murphy’s Law always applies.

Isn’t Murphy’s Law the thorn lodged in the back of every developer?

For those who are not aware, Murphy’s Law goes like this:

Anything that can go wrong will go wrong.

Just when you thought everything works, something would go wrong. I’m pretty sure every single software developer encountered this at some point. Some probably encounter this so often, if they get a dollar for every time this happens to them, they can already buy an Nvidia RTX 3090 at scalper price.

Mistakes happen no matter what we do. But the best course of action is to keep the mistakes out of end-users. Keeping the quality of work high is not just the QA’s job. It’s the job of every single member of the team, and that includes us, developers. Do some quick tests like unit tests or smoke tests before you even commit your changes to the repository. When QA discovers a bug, ask for steps to replicate the issue. And again, spending more time on good design will help in preventing disasters in the future.

GPL, MIT, BSD, WTF?!

One of my pet peeves is dealing with legalities when I just want to do my job.

Have you ever experienced looking for an open-source library, import it to your closed source project, then use it only to find out that the library is in GPL and you have to look for a library again? It happened to me before and it can be deflating.

The General Public License (GPL) is an open-source license that when used by a project, any project that depends on the GPL-protected project has to make their code open-source as well. It’s a good license to have if you’re dealing with open-source projects. However, it gets problematic when you’re working with a company that wants to keep its code private.

The GPL is not inherently bad. After all, it helped a lot in democratizing software development. But if you’re really concerned about licensing like me, GPL can be a tricky subject. Don’t even get me started with LGPL.

Here’s a quick and easy reference when it comes to software licensing:
– Copyleft licenses like GPL (and its more lax sibling LGPL) are good if you’re working on an open-source project.
– Permissive licenses like Apache, BSD, MIT licenses would allow you to use the project as you please.

Speaking of licensing and acknowledging the original author…

Make sure to acknowledge the author of the resource you’re about to use.

Sure, there are free resources on the internet for cheapskate developers like us. But make sure that you provide the proper attributions to the authors of those resources. It’s a common courtesy to do so. Anyone would love to be given the credit they deserve.

And please, don’t even do the Credits to the Owner (CTTO) thing. It’s stupid and it does not do anything.

There’s not one person with all the answers. Share if you know, ask if you don’t.

I remember one time when our boss made a slide about this.

The software development community is one of the best communities to be in. It really promotes the “pay it forward” way of thinking.

However, a lot of seasoned developers tend to act as gatekeepers and dismiss the inputs from the younger bunch. At the same time, some of the young ones dismiss the guidance of a seasoned developer as unnecessary.

One thing I’ve learned about software development is the best ideas sometimes come from fresh minds. Seasoned developers tend to have a specific train of thought that is hard to change. Fresh insights can come from fresh eyes. So we should not underestimate the new guys and instead encourage them to contribute to the betterment of the community.

As for young people, you should hear us old guys out. We’ve been writing software probably since you were in primary school. We’re not saying we have the best ideas and the best career choices around. But maybe you can learn from our good and bad decisions.

At the end of the day, we all need to be humble enough to listen to each other. Our community is growing bigger and bigger, and we’ll be the ones to push this world forward through technology. We better work together in harmony to get this done properly.

In relation to this…

Titles are just constructs.

One time we were talking about this, my fiancée and I had some fun and tried to make a bad syllogism out of it.

ALL Good Developers can be Seniors.
Some Seniors are Bad Developers.
Therefore, not ALL Seniors are Good Developers.

I’ve interviewed developers for job applications before. They come from different backgrounds and the level of experience varies from one person to another. Some involve upstart developers aiming for any position, while some of them applied for senior positions.

I am not in a senior position yet. But I’m usually the only .NET developer around for interviews. Since I’m not exactly a newbie when it comes to .NET development, I always am a panelist for such interviews.

One of the things that I observed is there are developers with less than 2 years of experience that can keep up with me in terms of skillset and development approaches, while some of the senior-level applicants don’t know much about new technology and their skillsets are either dated or insufficient for the current demands of new clients.

Inside the office, I’ve worked with senior developers before that even with lots of certifications, seminars, and projects under their belts, they still can’t communicate with clients properly, they still can’t deliver the proper solutions for the client’s requirements, and they’re not impervious to badly written code.

This does not make sense to me at first. But 2 things convinced me that titles are nothing but constructs.

The first one was when I met a new developer that can keep up with the requirements of my previous project. When I left that project, 2 developers replaced me. The first developer had as much experience as I do, while the other one is fairly new. The first guy delivered as I expected. But what amazed me is that the new guy absorbed our instructions like a sponge. He was able to deliver the requirements very well and he asks questions when he does not know how it can be done. In a short time, we were able to leave him with a few tickets and not worry about them screwing up.

The second one that convinced me was when I was working with another developer who came from a reputable company and is working for as long as I do in the software industry. That developer has been a constant source of problems. Unable to talk to clients properly about requirements, does not ask for help when they do not understand what needs to be done, their code is the worst I’ve seen in years, they can’t even keep their cussing on mute during a meeting. This person is supposed to be a senior developer.

If that doesn’t prove my point, I don’t know what will. Good developers are all around us. But just because one developer is new to the business, that doesn’t mean they’re not capable of keeping up. At the same time, just because one developer has a lot of years under their belt, they’re automatically good at the job. Don’t be fooled by titles.

I like this quote by a fellow from Tech Twitter Kyle Prinsloo:

The only difference between a junior and senior developer is the number of stickers on their laptop and how many cups of coffee they drink.

— Kyle Prinsloo (@kylepdotco) February 16, 2021

The only difference between a junior and senior developer is the number of stickers on their laptop and how many cups of coffee they drink.

Pick a tech stack and stick with it.

I’ve known this for years now. But I’m glad Tech Twitter boss Jack Forge agrees with me.

Pick a tech stack and stick with it.

You don't need to learn everything to build cool things.

— Jack Forge (@TheJackForge) May 8, 2021

Pick a tech stack and stick with it.
You don’t need to learn everything to build cool things.

You don’t have to know all the bajillion Javascript frameworks to make something. You don’t need to master every programming language that your eyes can see. You don’t need to know everything to get something done. All you need is the one you know and build from there.

Sure, your value depends on what you know. So focus on one thing and be an expert at it. Clients will always pick the expert who knows one thing over the amateur who knows a lot of tiny bits about things.

We all have a limited amount of time to live. Have some fun.

Speaking of fun…

Loosen up.

Work-life balance is the key to keep your mind sane in the software industry. We love developing software. But we’ll have a royal burnout if we don’t stop for a bit and enjoy life.

Throw that laptop under the couch and watch a movie. Spend some time with your loved ones. Learn to cook something. I don’t care what you do. Just have some fun!

Well-written documentation or well-written source code. Pick one.

Again, we only have a limited number of years to live. You can either focus on the documentation and write the best documentation of all time, or you write the source code so well that people won’t even need to read the documentation. Don’t even try to do both. Pick one and let the team do the rest.

There’s no I in TEAM and there’s always U in UNITY.

Nothing beats a team of developers writing software. Software development is hard and it’s better to do it with a team.

But being in a team is not always easy. To start with, a team is composed of individuals with different likes and dislikes, varying tolerances to annoyance, and different kinds of crazy.

We can go on and on about the good and the bad of having a team. But I only want to focus on a few things.

Work with the team and don’t be a dick. Involve the team in the work or at least let them know what’s happening. Ask for help if you can’t do it and offer help when someone needs it. Talk through your differences and always remember, don’t take it personally. You’re all working for a specific goal so you need to work as a unit.

But you can’t be in a team all the time. So…

…You have to be prepared to work as a one-man team.

It happened to me and it can happen to anyone. Sometimes your entire team is unavailable and you’re the only person that can help. When that happens, you have to be ready. Make sure you understand the project like the back of your hand. You should know the tools necessary to get something done. Learn everything you can about the project.

You should at least be capable of doing the basic tasks of your teammates. For example, you should be able to fill in as a QA by knowing the testing process, or you should be able to talk to your clients directly when necessary. I’m not saying you should be as good as your teammates. But knowing the basics can go a long way until your team can join you again.

Done is always better than perfect.

This is probably the best advice that I got. I’m really particular with the quality of work that I deliver and it’s a blessing and a curse. Sometimes I go in circles just because I don’t like what I’ve made at the time.

So if you can help it, don’t be like me. Get the functionality working, make sure that it’s readable and maintainable, do some quick tests, then send it for testing if you think it’s working as intended. Don’t let yourself get stuck in a loop. It’s always better to deliver with a passable product than being delayed with an excellent product.

What are the things you’ve learned in your software development journey? Do you think I missed something? Leave a message in the comments section and let’s have a conversation.

That’s all for today. Happy coding!