loading...
Cover image for 10 lessons from a software engineer & freelancer

10 lessons from a software engineer & freelancer

fzammit profile image Fabio Zammit ・5 min read

In recent weeks, I wanted to share some of the lessons I learnt throughout my career as a software engineer, freelancer and now running a software company.

Also, sharing is caring and if anyone can learn from some of my mistakes and observations, that would be awesome!

Onto the article...

Lesson 1: Marketing is your best friend

Learning the basics of marketing is handy and this does not mean understanding how to launch a full blown campaign on national TV. What I mean is:

  1. Build a portfolio
  2. Showcase EVERYTHING
  3. Tell everyone (friends, family, your LinkedIn network) about what you do

In 15 years most of my clients were referrals so do not underestimate the power of word of mouth.

Lesson 2: Go easy on the jargon

When dealing with clients/stakeholders/project managers, you want to have a good sense of communication, whereby you can both understand each other so as for you to deliver a product (software) that is about their goals.

Therefore, using phrases such as "The requests are slow, we should opt for in-memory dbs", may not be entirely appreciated. Bare in mind that not everyone understands technology the same way you do and it is important to respect it, especially when running your own show.

Learn how to use plain English (or whatever language you use) when communicating with non-technical stakeholders

Lesson 3: Programming languages are important but....

Whilst going through my Twitter feed, I see how individuals are obsessed on knowing the "best" languages or frameworks, which is definitely important BUT the "correct" approach for a project, is not just about the language or framework.

Languages are the tool to write the instructions, the art is in knowing the basics (Data structures, search algorithms, OOP, design patterns, test driven development etc) well so as to give you a proper understanding how to architect your software.

Moreover, different languages have different strengths and some might be more appropriate than others for that specific task.

Lesson 4: Ego, ego, ego

In my view, being a confident individual is somewhat important as it gives you that sense of re-assurance when making certain choices. However, as a software engineer I like to keep my feet on the ground. If you are asking why, here are the reasons:

  1. Everyone f*cks up, even the most experienced ones, so get off your pretty high horse :) I once by mistake executed sudo rm -rvf *, on a Linux dev machine where I was in the root folder of the file system. Oops! - luckily did no serious damage as I stopped it super quickly.

  2. It helps you become a better developer as you tend to question yourself from time to time.

  3. People appreciate you more as you are truly capable of looking for the 'right' solution rather than the one that suits your ego.

Lesson 5: Be transparent

Before starting any project, always be clear about what you plan on delivering and be transparent with the client or stakeholder. This gives the product owner, the re-assurance that you are putting your money where your mouth is and that you are professional.

Don't be afraid to say no, if you feel a task is going to derail your entire project plan.

Lesson 6: Project planning is key

When running your own show and things start to pick up, you will start to have more and more projects which is fantastic. However without any proper planning you risk disappointing clients, which is not the ideal situation.

We adopt these processes and tools to stay organised:

  1. Gantt charts for project planning, thus giving us an idea of how long a project will take, the sequence of tasks and allocation of resources
  2. We use Kanban (https://en.wikipedia.org/wiki/Kanban_(development)) within Trello to scope out all the tasks and this give us a good indication of current progress and what everyone is up to
  3. We organise daily stand-ups with the team so as to discuss issues and progress for each individual

If you ask, how does this apply to smaller teams, e.g. 1 or 2 people, I still suggest using Gantt charts + Kanban. Stay organised no matter how small you are!

Lesson 7: Have an understanding about UX

This applies mainly to anyone doing front-end work. Even though as developers, we are not required to know how to design proper UX. Experience showed me that it is good to have an understanding of what is a good user experience.

This will help you make better recommendations and build a piece of software that the end-user really enjoys using.

You can approach this in 2 ways:

  1. Team up with a good UX designer, if budgets are tight then opt for option 2
  2. Read up as much as you can e.g. https://amzn.to/2RqpM3q

Lesson 8: Don't be a know it all

Greek god

This kind of ties in with one's ego, but it deserves it's own lesson. As devs, we do sometimes feel this mighty power that we are like the Greek gods. This may be attributed to the fact that we are solving some real challenging issues and without diminishing anyone's achievement, we need to bare in mind that the dev team is not the beyond and all of a business.

There are other important business functions like marketing, SEO etc that have their own feature requests. In my experience I have sometimes seen these features being dismissed and claiming that they are not important.

This poor sense of judgement led to conflict between the departments, simply because of a lack of empathy or one not putting themselves into the other persons' shoes. From experience, I can tell that a basic change for the SEO department, could be a real winner for the business.

Bottom line, have respect for other requests and do your homework properly.

Lesson 9: Stay current

You never know enough, even after 15, 20, 30 years in the industry. Especially, when running your own thing, you need to make that extra effort to stay current as you don't always have the luxury of asking your colleague about what is the best approach.

So stay in touch with communities like this one and never stop learning.

Lesson 10: Build long lasting relationships

Building relationships is not only important in business but even when working in an organisation as you will learn from one another. More importantly you never know where life will take you and your own colleague or boss could be one of your first clients or future business partner.

The End

Hope you enjoyed reading and got some value out of this. Well done if you have made it to the bottom :D

Feel free to put forward any suggestions you may have. Stay hungry and feel free to reach out, happy to help out.

Posted on by:

fzammit profile

Fabio Zammit

@fzammit

Software engineer and founder of Root Codex, a software company

Discussion

pic
Editor guide
 

Awesome post πŸ‘

I was just talking to a colleague of mine about that UX knowledge point yesterday.

When running a start-up with no designer or a UX guy at least having a "good enough" product UX is really vital to market penetration.

This adds up to what you pointed out earlier about "putting yourself in other people's shoes", this is a part of that, IMO developers must put themselves in the end user shoes and use the product, they would notice a lot of improvements that could be made, UX wise, and feature wise as well.

 

Very good advice! As an ex-freelancer who is very curious and loves to experiment and learn through side projects, the only advice I don't 100% agree with is "Showcase EVERYTHING".
I did that and it attracted a too wide array of customers and projects, mostly on topics that I didn't want to work on anymore.
As replying to potential clients takes time and saying no is not easy nor fun, I would recommend to pick a speciality / area of focus and/or a clear set of technologies you want to work with, and only share a portfolio that is related to that.
Also keep in mind that the projects that you take will influence the kind of potential clients that will contact you => only accept the kind of missions that you would accept to do again in the future.

 

Thank you :) glad you found it useful.

Yes, and that is also part of being a start-up where you have to wear multiple hats in order to get the product out there.

"IMO developers must put themselves in the end user shoes and use the product" - that my friend is the holy grail. Keep repeating this to everyone!

 

Good points, and well written.

I used to freelance years ago, and then I worked at a couple startups as they progressed, eventually working dev team manager, project manager and product manager roles. I also spent a couple years teaching at university and college programs.

I'm now back to freelancing and the quality of my work and experience is completely different than it was before, mainly because I learned all of the lessons you've included here.

 

Thank you for your comments πŸ™‚

β€œthe quality of my work and experience is completely...”....that is very true and I can relate to this.

In fact I would recommend anyone to try working for companies/startups even when a freelancer.

 

Thank you for your post.
I'm trying to be a freelancer, but I don't have more experience with this position, too hard to get the first job among developers when I just started
Do you have any idea with mine case?
Thank you.

 

I suggest you put together a portfolio of what you did even if they are projects you did for yourself.

Once you are done open a profile on Elance and Upwork. That should give you a good start but the most important is perseverance, never give up, as cliche as that sounds. Wish you all the best of luck 😊

 

Good and valued inputs. Very true. Happy new year. Thank you.

 

Thank you for your comments, same to you!

 

Great post !
I would love to see a list of ideas of this point : Lesson 1 - Showcase EVERYTHING

 

Thank you :) Sure I will write a new post about this in the coming days.

 
 

Haha I've made the exact same rm -rf / in my first job... Hopefully SVN saved us back then. God, SVN...

Anyway, great post especially about ego!

 

Haha, damn...... Thanks for taking me down memory lane.

SVN rocked at the time, then Mercurial was kind of the new kid on the block.

Thanks for the comments πŸ™‚

 
 

Thanks πŸ™‚

 

haha dev.to actually helps according to this article πŸ‘agree

 

Ahh, might as well say it. While trying to configure lamp on my machine I removed root privileges from root. I couldn't fix that because I no longer had permission as root

 

Thanks and well done for sharing, it will only make you stronger πŸ™‚

 

Fabulous post, great advice.

 

Thank you :) Highly appreciate your comments

 

Thank you for this post Fabio! Great advice

 

Thank you, glad you found it useful :)

 

Awesome post I find that the jargon part is always something I had problems with.

Which turns out to be really bad whenever I explain it in a none technical way.

 

Don’t worry awareness is the most important, plus this still happens to most of us.

The most important is trying!

Thanks for the comments πŸ™‚

 

Yes! and especially on point 3! I've been meaning to write an article on this subject for a while now. You should always pick the language that suits your application, never the other way around!

 

Write the article, the more awareness we raise, the more we grow πŸ™‚

 
 

Great post, I agree with all your points 100%!

 

Thank you πŸ™‚

 
 
 

Lesson 10 is the hardest ;_;

 

Yes, however the best way to go around it, is to put yourself out there. Post articles, tell everyone what you do, what you enjoy and get very involved on Twitter.

I can see you have some Github repos, promote what you did :) I am convinced that your work will be appreciated!