Author’s note: I originally intended for this to be a single post containing some of the lessons I had gathered over the years of doing website development and design. Alas, it proved to be a little bit too long (spanning over 3000 words and 15 pages), so I decided to break it up a little. 

It is strongly recommended that you read part 1 of these series before moving forward onto the next, if only so I may let you know of the situation that inspired me to write these pieces of advice here for everyone to see them.

But, now that we’ve cleared that out, these are the last 6 pieces of advice I would like to share with you all:

6.- Pay your technical debt forward.


You’re eventually going to have to work on somebody else’s code and, more often than not, you’ll find that having a clear idea of what they’re trying to do is half the battle.

And some of those times, you’ll also notice that understanding everything is not really necessary to do what you were sent there to do in the first place.

So what happens then? Well, sometimes you’ll go the extra mile and try to make sense of everything, and then seamlessly integrate your improvements into the mixture.

Some others you’ll see that your change doesn’t really affect the rest of the code; You get a free pass that time.

… And there’ll also be times when you have to hack your way to sanity.

The result of this ends up being something that none of us are really proud of: hacky, hardcoded and unstable code that looks as if it was put together using actual duct tape.

You may know that someone (hopefully not you) will one day find your abomination, and then be forced to tussle with it for dominance. But for now the day has been saved and, in the end, isn’t that what really matters?

This is Technical Debt: findng the easy way out now and worrying about the true solutions later.

And don’t get me wrong, sometimes you get away with it.

But, what getting away with hacky code (and technical debt) really means is: somebody else is going to have to pay your tab. And that one might as well end up being the whole project.

A surprise like this can lead to a seemingly easy task becoming a month-long epic.

The sad part is that the ones paying the debt will be in no way to blame for the mess. And you know? That person will be you every now and then, even if you weren’t the one who created it in the first place.

The good news is that there are things that can be done about this situation: We can ensure that peer reviews are set in place to prevent this kind of behaviour, we can automate linting tools to help standardize code, we can encourage pair programming, etc.

Can we fully avoid technical debt? Not really. It’s pretty much impossible to ensure that we never have to pay someone else’s tab. But we can create good will by paying our technical debts forward:

Do the hard work today to keep others from doing harder work tomorrow.

The secret lies in picturing the experience you’d like to have when first encountering code you didn’t write, and then trying to create that experience for others. It may take a little bit more time, but it can really make a difference in the long run.

I won’t lie to you; this is one of those things that requires some experience to get into the habit of actually doing. But it really only takes one run-in with somebody else’s debt for your eyes to be opened.

7.- Avoid Frameworks like the plague.


Every so often I get a question from a new developer, it always goes something like this: “Do I really need to know Programming Language to work on Framework?”. And before I give my answer to this question, let’s first try to understand the real problem.

Most development positions (in the Web Industry) as of January 2017 make at least some mention of a certain framework that would be “Good to know”:

This in turn makes newcomers believe that you need to know a framework in order to secure a job opportunity. And in a sense they are right, which is a shame because jumping straight into a framework can really stump a new developer’s growth.

Let’s see why:

  1. Frameworks are not agnostic. They come with their own views, opinions and culture. They’re intended to be adopted with a specific mentality in place.
  2. Frameworks abstract some (if not most) of the quirks and difficulties of any programming language. And while these could be cited as some of their greater qualities, they also abstract some of the understanding that would come with solving these scenarios. And in doing so they can stunt the growth of an inexperienced developer.
  3. Most frameworks are like a mini-programming language. They have their own methods for doing things, sometimes even their own syntax. This makes it so it isn’t uncommon to find seasoned Framework developers that don’t fully know the ins and outs of the Programming Language it is derived from.

So to answer my question from before: Yes, you do need to learn the language first.

This isn’t to say frameworks are bad though, I myself am a huge fan of many of them. Hey, I’ve even written about some of them!

All I’m saying is: You’ll run much better once you figure out how to properly walk.

8.- Get known in your community.


We already talked about how knowing the right people is going to get you some of the best opportunities that you’ll ever come across. This is the counter part to that.

This is very important, so I’ll keep it simple:

Get people to know you and your work.

As a professional there are very few things that are more important than your own personal brand. And building one takes time and effort, so any small little thing you can do to get noticed will add up in the end.

Here are just a few tips:

  • Create GitHub repositories for your side projects
  • Answer some questions on Stack Overflow (it is also good to be able to give back to the community.)
  • Attend the local Meetups in your town. Become an active member.
  • If you’re a front end developer, Codepen is a great place to display your work.
  • Start a Blog.
  • Contribute to open source.

The important thing is to keep yourself moving and involved in the things you’re interested in. If you keep on producing good work, people are sure to notice.

9.- Test some code.


Nobody likes having their code criticized.

As creatives, we tend to grow fond of the things we make, even when it goes against our best interest to do so. We spend a long time writing line after line, making sure everything works the way it’s supposed to, we find clever ways of doing things, and learn every step of the way.

So when it finally comes the time to send the code off to fend for itself. We can get a little defensive

And then comes the tester, whose sole job is to find the cracks in the things developers build.

There’s no wonder the relationship between these two kinds of professionals can get a little rocky to say the least. Which is very interesting because, despite their differences, they’re both dedicated to the same purpose: Creating the best possible software.

And it is only by going through the hands of an experienced tester that the best releases can be born. They are the ones who set the standards by which we judge every patch, and separate the best from the rest.

Testers live at the frontlines of the army that is a big software company. They stand to protect the customer from as many defect as possible and, in doing so, increase the overall quality of the finished product.

It is a very complex discipline that combines business knowledge, design principles, coding (for automation;) and most of all: Determination. Because our job may be done the moment that “it” works, but testing could really go on forever.

Now, I’m not suggesting you dive fully into testing as a discipline (unless you want to.) All I’m saying here is to try to put yourself in their shoes, even if just a little: Try doing some Manual Testing, investigate how Automation works, learn how to Unit Test, etc.

So what can testing code really teach you?

  • You’ll learn that mistakes are there to be found and corrected.
  • You’ll gain an eye for defects, you can thank me later for that one.
  • Seeing other people’s code will inevitably teach you new things.
  • You’ll get familiar with the roughest edges of your platform.

And if nothing else: You’ll get a feeling for the real scenarios in which your code gets used.

Besides, techniques like Unit Testing and  Test Driven Development deserve more than their fair share of space in an experienced developer’s toolset. Learning them will help your finished products closer resemble what the business actually wanted.

10.-Stay humble, stay hungry, and never stop learning.


“Nothing in this world can take the place of persistence. Talent will not; nothing is more common than unsuccessful men with talent. Genius will not; unrewarded genius is almost a proverb. Education will not; the world is full of educated derelicts. Persistence and determination alone are omnipotent. The slogan Press On! has solved and always will solve the problems of the human race.”
Calvin Coolidge

I chose point number 1 and this one for similar reasons, as they are the two most important lessons I want to leave you with.

There will be many moments in the following years in which you’re going to feel comfortable.

It’s going to be pretty great: You’re going to be the guy that knows everything, everybody will to come to you for advice, everyone will know who you are. You’re going to feel at the top and for very good reasons, because you earned it.

It is at this point, when you feel at your highest, that it can be the easiest to fall asleep on your laurels. And that is my last piece of advice:

Stay humble, stay hungry, and never stop learning.

You didn’t get to that point by being comfortable, you didn’t become the very best from taking 2-hour coffee breaks, you didn’t rise up to that position through repeating the same mindless tasks everyday.

No. You pushed forward. Put in 16 hours when everybody else was clocking 8. Took on all the challenges. And learned what you didn’t know. It wasn’t always easy, but you did it all with a smile on your face.

So what can you do? There are plenty of things on this list already, I invite you to put them in practice. But even if you can find nothing of use here, I’m pretty sure you can come up with your own after reading this; just remember to continuously push your own limits.

These are some of the things I learnt throughout my years developing websites and applications. They don’t necessarily apply to everyone, and same as with all advice, you’re invited to take them all with a grain of salt. That being said though, I do hope you can find some of it useful.

Do let me know in the comments if there’s any other piece of advice you’d like to give to up and coming developers, or if there’s anything you’d like to add to the points I wrote in this post.


My name’s Orlando Paredes Hamsho. I’m a 25-year-old Web Developer living (mostly) in Guadalajara, Mexico; albeit I intend to move pretty soon. Apparently, I also run a blog now, and have been doing so for a while.

Write A Comment