To freelance or not to freelance: that is the question

I must admit that I always thought that term “freelance” was associated either to (1) that small side project you have besides your actual job to get some extra money, (2) graphic designers, or (3) coders with a lack of enthusiasm to be challenged. In the last group, I used to imagine a young guy who is not committed to or not prepared enough for getting involved on a serious project. I have no clue where this idea came from. It was probably more a perception than an actual idea, anyhow it was there.

I am from Argentina, and in my country you get lots of benefits if you work for a company such as sick days, at least two weeks per year of paid vacations, ten days for exams if you are a student, and so on. I spent 9+ years building software in industry as a Java Developer, Tech Lead, and Team Leader. I had so much fun, I learned very much, earned way more money than an average salary in my country, met great people, and worked with large distributed systems processing tens of thousands of messages per second. But not everything was great, although my project was overall quite challenging, there were long periods of time where the project was just so boring. That means no challenges, no chances to learn, no new technologies; in essence, not feeling that I was doing something valuable. I also had to commute two hours a day, had very limited opportunities to travel (which I love doing!). I eventually became quite an expert in a set of technologies but did not have exposure to other technologies I longed for trying.

During the last three years, I lived in Irvine, California, where I got an MS in Software Engineering from University of California, Irvine. That was an amazing experience in several aspects, but especially, it gave me an opportunity to see the huge variety of things people are working on in technology. I assume and I am looking forward to confirming that working remotely as a freelancer, will give me chances to work on great projects regardless of where they are geographically located.

Some time ago, I got to know about Toptal. After looking at the website, reading blog posts, and talking to people working there, I found out that it is not as the other software developer platforms I knew. Well, at least it does not look like that but it looks great enough for me to give it a try. I will be going through the screening process soon, and I will be posting here my experience.

What surprised me considerably is that the software developers working at Toptal are very knowledgeable. They were not those rocky coders I was expecting to find. They do know but, even better, they share their knowledge. There is a feeling of community, and it seems a great place to learn from others and to share what I know. Toptal claims to hire only the best 3% of the applicants, meaning that joining their Software Developers Network puts you in the top 3% of a set of software engineers. That sounds challenging but at the same time, it has a twofold benefit: you work with the best software engineers and you get recognition for being part of it.

No place will be perfect but so far Toptal looks like the sweet spot between freedom, learning, and working in cool projects apart but not on your own.

5 Reasons to Think twice before changing a design

You’re required to implement a system, and you receive an already created design. You get one or more class diagrams, maybe a sequence diagram too. Perhaps you’re lucky and you even get an architectural diagram. You’re a great designer and you won’t start the implementation before understanding it and verifying that it is correct.

You get the overall idea and it looks correct but it is just horrible. Well, it seems to work but it is obvious that there are some ways to design the same thing that are much better. You’re tempted to make it simpler, more elegant and to implement design patterns that perfectly fit for that situation.

Don’t do it unless you really know what you’re doing.

I’m not talking about becoming an over-conservative-passive-just-in-case-I-would-not-change-it software designer. Not at all. You should always be proactively thinking about how to improve what is already done. However, there might be serious reasons behind for the original designer to do it that way. How about if:

  • There is another piece of code depending on this API.

  • Some non-functional requirement is so critical that you need to imperfect the design to boost that aspect.

    • Think about performance. Perhaps this particular piece of code is going to be executed a huge number of times per second and it has to work really fast. Maybe reutilizing an object or not calling a third method to avoid stacking execution frames could become a good idea. Non-functional requirements have to be considered before creating the design.

  • Your design is more elegant and flexible but it would require 15% extra time. Well, 15% for a much better design? Worth doing it! Maybe not. There may be critical commercial reasons to deliver the product earlier. Even having to pay that cost. You will increase your technical debt and it will have to be paid sooner or later, but maybe this time, it really has to be later.

  • The new design is built on top of an already existing piece of code or framework. That dependence might be so critical and/or buggy that the company does not want to take the risk of changing it. You could wrap it, abstract it and improve the design. However, don’t make that assumption unless you are familiar with the creature.

Now you might be thinking “I understand but how do I know?”. Ask.

The original designer should have included a Rationale in the design explaining assumptions, compromise decisions and trade-offs, but maybe he or she didn’t. There are rare examples of great software built by heroes but it is plenty of fantastic products created by teams with good technical skills but better communication capabilities.

To sum this up, all the software designs have the same level of quality, at prior. Once you know what they are for and the context in which they were created, you can evaluate them.