10 hard-learned Lessons for aspiring programmers

Career 6 Minutes

I have made a couple of mistakes over the years and wanted to share those pitfalls so upcoming programmers know what to avoid and what works.

1. Focus

You can’t do everything – I don’t think it is possible for one person to simultaneously be a pro at writing high quality code, network engineering, computer hardware and machine learning.

Some years ago, a much younger and naive me wanted to do everything in software engineering, use several operating systems and know enough about network engineering. Did I succeed at that? No, I just diluted my efforts and wasted loads of time (was fun though…).

Laser-like focus is essential as the field of computing is extremely wide. Decide the field you are interested in, narrow down a learning path and get your hands dirty. For example, if you choose software engineering, you’ll have to select one of three tiers: web/mobile/desktop. Once decided, just work on completing a sample project. The more projects you have under your belt, the better you become and the more learning you do.

2. Dedication

You probably won’t become good enough in one or two years. That learn * in 24 hours book? Gives you a feel for what the language syntax is but there is more than that to mastery. You need to learn language idioms, problem analysis and clean architectural design.

This take time – a lot of time: Norvig put it at 10 years; just like mastery in any other field. It is a long haul so set your mind at it and you should hopefully start seeing results in about 5 years.

3. Consistency

Little drops of water consistently dripping on the same spot can wear down rocks.

The rush of excitement you feel at the beginning is eventually going to wane. Once it becomes a dreary old routine, what will keep you going at it? Consistency and habits can compound in surprising ways.

Assuming you are 1% better each day; after a year; you’ll be about 37 times better. Conversely, if you lose 1% everyday, then after a year you’ll be 0.02 of what you were. This is an extreme example but …

Small incremental progress over a long period of time leads to big increases. For example, a developer that dedicates 25 minutes daily to improving his skills would have spent ~183 hours honing his skills after a year. That’s nearly a month of intense study time. Can you study intensely for one month without burning out?

Can’t afford the 25 mins a day? How many minutes do you spend daily on Facebook? Multiply that by 365 to see where your time is going… Oh.. add in some more hours for games, TV and Twitter too. You see little things add up quickly over long periods of time.

Now once you are consistent, what’s the next step?

4. Seek mastery before moving on

Now that you have focus, the next obvious step is to stick to a path. Frameworks pop up every second in software development but hopping around from one framework to another is ill-advised: you would likely end up as a jack of all frameworks and master of none. I agree and encourage exploratory learning but jumping on every fad bandwagon is going to get you nowhere. Rather, make a strategic choice, stick to it and commit to learning it deeply.

Does this make you less marketable? Afterall, you want to be that guy who knows how to write code in 10,000 languages. Mastering a few increases your worth – you can now charge people more for expertise in your domain. Think of it this way, if you want a dining table masterpiece, what kind of carpenter would you prefer? One that specializes in dining tables or a generalist?

5. Learn the fundamentals

I can’t emphasize this enough. Let’s take a story: EmberJS and AngularJS brought about widespread adoption of 2-way binding across UI interfaces and this in turn triggered the proposal for object.observe as a JavaScript language method. More recently, the new path has been reactive programming and virtual DOM, eliminating the need for observables. You guessed it, object.observe got retired from the language. Now, a counter example, Dijkstra’s algorithm has been around since 1956 and it is still in use after 60 years! Can you beat that?

You have to know algorithms, data structures, operating system fundamentals, caching, Mathematics, etc. These concepts are language agnostic and provide a solid basis for solving new problems. That cool functional reactive somersaulting framework you are harping about today? It may be gone in 10 years. Fundamental CS knowledge? Evergreen, safe investment.

6. Be Humble

There are two things you should keep in mind:

  • There would always be a programmer better than you
  • You probably overestimate your skills

Do you disagree with me? Check out your ranking on the programmer skills matrix. Next, read Micheal Church’s excellent adders analogy. Unless you are already at 2.5+, there is no need to brag about your skills. Instead, quitely keep pushing the limits and some day you hopefully would earn bragging rights.

Humility is a great characteristic to have – there are a ton of things you do not know and need to know. And it takes time to reach the levels others have reached. Even if you think you are a rockstar, people generally appreciate a humble confident programmer who doesn’t rub his ‘magnificence’ into their faces all the time.

Need a yardstick to measure your progress? Periodically check back on both lists to track your progress.

7. Learn how to communicate

Most of software engineering is not about writing code – a large amount of time is spent discussing projects, evaluating designs and interacting with customers. The ability to clearly convey thoughts is one most programmers lack and it is a clear differentiator.

Being able to express yourself means you can get help with problems because you can explain them to others, it also means you can convince people to join your open source project or even adopt your architectural design. All these come from being able to sell yourself and your thoughts.

Communication is not limited to speech only though, writing well is another part. Want to improve? Write more, speak more, volunteer to be a spokesperson – practice makes perfect.

8. Get a mentor & be visible

Stand on the shoulders of giants to see farther. You need to avoid making pitiable mistakes if you can, accelerate your growth and ensure you are on the right path. Great mentors help you grow, introduce you to their networks and provide insightful feedback. They have a lot of experience which you don’t.

Don’t hide under a rock! People should know you for what you do!! Would you buy Microsoft Word if you never heard of it? Seek out peers in the community, interact with them and share ideas. Help one another grow and help influence the community. Being visible makes it easier to find mentors, jobs or even new freelance opportunities. Don’t want to go out? Then create a blog, comment on blogs, release software on Github or participate in fora.

9. Be open

No, your favorite language/IDE/tool is not the best thing since bread and butter. It has its own flaws and strengths.

You can have pretty strong opinions on anything, for example, favorite languages. However what you shouldn’t do is get so tied to some language that you refuse to try out any other language. There would always be situations where your favorite tool doesn’t cut it; in such scenarios, find the best tool and deploy it.

A Toyota Camry can probably carry logs of wood but you are better off moving such with a heavy freight truck.

I used to think I understood recursion until I read SICP; I was forced to write programs without resorting to variables and suddenly, simple toy programs became quite challenging. Exposure to various tools will empower you with various problem solving approaches. This is always a good thing since software engineering is all about solving the right problems.

10. Startups can be overglorified

I think most times, the start-up concept is overglorified – it involves a lot of work, huge risk and great rewards on success. However, the idea that once you make that awesome piece of software, it’ll automatically sell itself is mostly false. That rarely happens.

The saddening part however is that most of us do not know how to deliver good software, talk less of selling software. Yet, they want to run the business. Imagine you handing over a truck on the highway to an unqualified driver who barely knows the ropes. What’s that? A recipe for a crash right? Yup, then why do we do the same with startups?

Software is typically not the critical part of most businesses, rather meeting the user’s need is. You need to learn how to write software first, then learn about business and entrepreneurship – creating a MVP, build-measure-learn cycles, customer interactions, acquisition funnels, maintenance and support, delivery pipelines, execution and meeting competitors. Now, you know this, you can see the bigger picture – the software is not the goal. The business is the goal – the best piece of software that no one uses is a failure.

There is nothing bad with working in an established shop for some time to learn the ropes, creating connections and learning how business is run. You can even start testing the waters and at least you have a safe cushion if things go south.

And that’s it! Did I miss out on anything? Do share your thoughts in the comments or follow me on Twitter.

Published

29 thoughts on “10 hard-learned Lessons for aspiring programmers”

  2. Great piece, but i have reservation as to choosing out of the three aforementioned options, i.e, Mobile/Web/Desktop. For a young developer, won’t choosing just only one at the initial stage be limiting.

    Like

    Reply

    1. Thank you very much for the feedback.

      No it is not limiting, rather it enables you to rapidly learn and accelerate. I have done the same before – hopped around, it wasn’t effective and didn’t enable me grow. Programming languages are tools – once you know how to build something with a tool, then it is easier to build ‘other’ things with ‘other’ tools. However, if you spend your time hopping from one ‘tool’ to another, then you dilute your efforts and take longer.

      To be pragmatic, I know there are times when you have to be broad. I am not against that, I prefer T-shaped skills. Broad coverage and deep insights in specific areas. So learn web (or mobile or desktop); be a master of that and you probably won’t be limited. However if you know a bit of all three without specialization, then that is limiting because you have to compete with specialists in their domains.

      Like

      Reply

  3. You write really good overview articles. That’s a skill all by itself. Specific comments:

    1) While focus is undoubtedly necessary, too many technologists of all stripes become too specialized and can’t see beyond their small domains to the larger issues. This is another instance of being very good at how to do things, but less so at what to do.

    6) Great teachers teach by example and real experts are recognized by others who see their product. If you’re in an interview, then, by all means, talk yourself up, but doing so in other contexts builds walls between you and others.

    10) Good point, but many successes have come from people just striking out and learning the necessary skills as they go (or networking with others who have those skills). You’ll never know everything you need to know before you start anything non-trivial, but that should not stop you from trying.

    Like

    Reply

    1. Thank you very much Joseph – I do appreciate and look forward to your comments, they are always insightful.

      1. I do agree with you on this. Yeah, it is very possible to have tunnel vision and that is not a good thing. T-shaped skills win me any day any time.

      6. Absolutely, the skills should the ‘talking’. :)

      10. I do agree that 100% knowledge is not needed; however I think jumping into something blindly and not listening to input from others can be risky. I have had experiences with devs who had no business knowledge, didn’t know they had no basics and were not willing to learn too. Ultimately, we all learn but I do wish informed decisions could be taken at times…

      Like

      Reply

  4. Wow. Nicely detailed and explained. Thanks alot for this. other upcoming programmers needs to see this.

    Like

    Reply

  5. Point 5 and 10 really killed it. It’s just funny sometimes when you meet some people calling themselves “Programming Lord or Badass” without even knowing the fundamentals of computing. I think developers should try to know the basics, it helps a lot in writing performant codes (You will get to know when its appropriate to declare a variable, when tail recursion optimization is required even if your programming language or development stack supports it, where to use array based or linked based sequences, divide and conquer techniques, greedy algorithms, edit third party Javascript component to suit your needs e.t.c). Here in Nigeria, startup can be really overglorified, I think people are just wannabes here with little or no knowledge about what it takes to manage a successful business (I really can’t stop quipping the first day I heard Yabacon valley).

    Like

    Reply

    1. Oga Seun, awon programmer ni yen :)

      lol @ Programming badass. Have you heard of the Dunning-Kruger syndrome? That might be a manifestation of that.

      What do you think could be done to fix the situation?

      Like

      Reply

  8. Hello Good day I’m David. I read ur email. Actually I’m subscribed to ur site’s newsletter. So I read ur email on advice for aspiring programmers. I have lots of questions to ask, but it won’t be convenient in email. Can I have ur whatsapp. I also need some solid pro advice as well.

    Like

    Reply

  9. You mentioned SCIP, i think the best advice you can give anyone that starts programing to use that book as a guide line it handles practically everything. It’s like the matrix take the blue pill any book and then the red pill of SCIP it will take yoi throughout the wonder land of the machine and it will take you very deep into the rabbit hole for being just one book,
    Functional, logic, imperative, object oriented design, high order functions, machine language, simple garbage collection, custom evaluators and interpreters and so much more all in one book if i had know this book before i started programing i would definitely took the red pill. All other programming languages after that book are just syntax nothing more and nothing less. If you learn throughout java or C# to much time is invested in learning things that aren’t needed as a programmer, windows properties ide usage of objects before you know what they are and so on. SCIP ironically enough my bible (if you read first page at least)
    Other than that i liked the post some small things here and there that i don’t fully agree with but none the less a good post

    Like

    Reply

    1. Thank you very much Dylan.

      I do agree the SICP book is a classic that any one who is serious about programming should read – however it does require a significant commitment and a lot of determination to complete.

      Nevertheless, those who complete the journey emerge significantly stronger.

      Just curious; which of the points do you disagree with? I’ll very much like to hear your views.

      Like

      Reply

  10. Thank you very much. I guess I have a long way to go and should try and master in one aspect first then trying to know all the stuff in the IT world.

    Like

    Reply

  11. Wow, great post, definitely all useful advice. For #8 (get a mentor), how do you recommend going about that? i.e. How do you narrow your search to find the person that you want to be your mentor? For example, my “mentor” (in quotes because we consider each other as friends) is not a programmer but adept at business and knows a lot about the startup cycle. So in this case, I wouldn’t grow as a programmer but I would as a business person. Do you recommend having multiple mentors for multiple areas?

    Like

    Reply

  12. Hi Abdul, great post! One question, re. #8, how do you recommend going about finding the right mentor? I mean, there are so many out there specializing in a variety of fields, how do you narrow your search? For example, my mentor is adept at business (the whole startup cycle you mentioned) but doesn’t know how to program. So naturally, I have become a better business person but I wouldn’t say a better programmer. Should we have multiple mentors for multiple areas?

    Like

    Reply

    1. Hey Zenultima,

      Nice to hear from you and thanks for the feedback.

      Yes, have multiple mentors – I do have a few too. Each mentor would give you input related to their areas of expertise and you get to join multiple views.

      Liked by 1 person

      Reply

      1. Cool! So what would you say are some of the things you should learn from your mentor? I mean, obviously they’re not going to tutor you on all the nitty-gritty details, and time with them is valuable, so what should we seek when we spend time with mentors?

        Like

      2. Depends on you.

        For me, I discuss my challenges or issues I have run into since the last meeting. At other times, I seek their insight regarding my plans or ask where they think the industry is going.

        Like

  14. Pingback: What it means to be a Senior Software Engineer – CodeKraft

Leave a comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.