Marketing as freelancer

In this post, I will consider several problems related to selling your skills (programming) with reasonable price. How to strategically sell your skills in such way that you won't mess up the market, but still evolve in reasonable speed.

For programmer, there are the following considerations:

In software world, working with more complex problems:

1. Is more interesting.
2. Lets you develop more.
3. Adds more value to your portfolio.

So, all programmers are interested in working on more complex projects. Work providers can utilize this fact to get things cheaper.


There are also the following considerations:

• As more complex the problem, as less people able to solve it. Thus, price for solving more complex problems should be higher.
  
• You often don't find job providers able to pay for solving more complex problems. Thus, if someone able to pay for less complex job wants something more complex, they would hope to get it for price of less complex problems.
• Getting prize up for more complex problems makes more people wan't to learn solving those, thus it's for general good.
  

So, a programmer:

• Should want to get hands on solving more complex problems to get all kinds of personal gains for that.
• Should want to not solve more complex problems with price of less complex problems.

Now, you have a problem - you don't want to mess up the market (be it local or global market), but you want to develop and prove your skills in solving more complex problems. You are annoyed doing some simple and boring routine work, but you also don't want to give away your really valuable ideas and knowledge (collected over time) for that price to those job providers. It seems like a trap, which it is - but, bad solution is better than no solution.


For job providers, also the following is true:

• Less experienced programmers fall to that trap easily.
• Less experienced programmers fail more complex projects often and the general prize, thus, with risk included, is high - you will need more experienced programmers on that project.
• More experienced programmers generally have thought about the problem and worked out some solutions.

This also shows that less experienced programmer, who works with higher risk, should make their prices smaller so that risk is included - if risk is 50%, it would be good to make your price at least 50% smaller, which might already be the price of less complex problem you are easily ready to solve.


Anyway, the topic should be analyzed in written form and I haven't seen neutral analysis of it around in places easily findable for me. So, I try to do it here.


Now, you want:

• To sell your assets.
• To get their true price.

You should not know your price or sell yourself. You should know the price of your work and sell your work. Price, happily, does not come from complexity or skills.

Price comes from the following factors, at least:

• How many people are able to achieve the results - this, actually, is the measure of how much homework they have done. How much they have been able to allocate their time to learn new skills; how much work they have done to develop those skills in real experience (this means often choosing less guaranteed jobs with higher risks, living less stable life to get more opportunities). If all people are able to achieve the results, the skill is not worth much; if many people are able to achieve the results, this skill is worth much.
  
• How hard it is to achieve the results and how talented one must be for that - this has something to do with genetics, but also with determination and some kind of self-discipline, this ability grows in experience, but not so much with theoretic reading and discussions (anyway, it can't grow much without being backed up by theoretic reading and discussions).
• How much client gains from those results. As more the client gains, as bigger the prize.
• How much general public gains from those results. As more they gain, as smaller the prize, because general public is not often going to pay - this is more like a cooperative effort.

The last fact, surprisingly, can be used to find a good solution.


As an experience and for leaving positive trace, one can work hard on GNU projects. Be selective.

• Choose the projects, which can be used for general good and not for general bad; also choose projects, which are highly needed for general good, even if they can not be used for general bad.
• Choose the projects, which give advantage to people, who are working on projects, which provide general good. Warren Buffet has suggested to buy small pieces of companies as if you buyed the whole company - good investment comes from such thinking, also the experience could be used later if you actually do. So, choose projects having that kind of thinking like if you was leading the whole world - think through complex strategies, buy your small piece of projects, which are needed to fulfill those strategies. If you are right, there are many like you.
• Choose the projects you are able to finish. No-one blames if you don't, so take a reasonable risks to keep yourself on (your) cutting edge - anyway, you and the world get the most experience and other results from projects, which are carried through to the end.
• Do not create things, which don't yield so much general good and which you could sell with reasonable prize, should you get the opportunity unless they are really needed. Do not blow up the market. You need the market and you don't have that much really valuable ideas.

This is for your free time.



Now, how to create those dumb and boring projects really fruitful for you if you are not selling valuable things under market prize?

• Do not try to make them more complex for yourself - you take unreasonable risk, lower your prize and leave really bad trace if you fail. Find the effective strategy.
• You are not selling complex solutions, but you can do really good job on managing and planning. Managing and planning is needed anywhere - use those opportunities to grow your managing and planning skills. Optimize the process and find ways to do those things faster. Keep the resulting methodologies to yourself unless you are paid for them - or open them for general public. In case you develop a powerful engine actually doing your job, don't give it away as bonus; in case you get better, just tell that you could become a good leader in that field for now.
  
• Even if your prize per unit is market prize, your real price can grow as you advance.

Anyway, if you are doing boring routine work - which is not anymore so boring and routine, as you can see -, keep the free time needed to find more interesting problems. You are not so needed there - anyone could do your job.


There is additional problem:

• Many job providers are not going to pay more for faster working. They want to control you - to not pay you so much that you would become free and go away. They think that you can live if you can buy food and pay for your department.
  

This is not easy to resolve without finding providers, who can. You might not find them so easily. Consider also than as you get better, market average gets also better - your new strategies might simply keep you as average or a bit over average even if you work twice as fast as in previous year. Many job providers also pay to beginners a bit more than they deserve, hoping to get this money back when they get faster. You could think that you deserve more than you actually do.

So, some possible solution: as you get faster, spend more time in getting more faster and better. Make your work broader and go to tasks, which you can't do so fast, so that no-one will notice. You always need to get as much as you put in, minus the money you pay to your job providers for some excellent work on finding new tasks, utilizing your skills where someone really needs them and handling all kinds of problems for you. As long as you are not so good in that part, you should be conscious that if they work out how to use your skills in real world so that they are really needed and fit somewhere well, they are doing a lot of the real engineering. So, if someone gets really rich with energy they got from your potatoes, they have done most job of finding their place. If you grow potatoes because you like growing potatoes, you are working for yourself and not for common good. Otherwise, you should consider getting some skills of managing and analysis as well.


How to calculate the prize:

• Consider the speed of finishing goals. Try to find out average market prize plus average speed of others doing that work. Doing it twice as fast should give you twice as much money.
• Consider, what people gain from that kind of job - not what your client will get, but what some average customer needing such kind of work would get for it. Otherwise, anyone could simply lie you that they get less than they actually do - this makes your price smaller if you can't think along to make your customer really win as much as possible from your work. Anyway, consider that working along if you do is a job and has a price, you spend some additional hours on it. If this job is more valuable in theory - even if it's not creating that value in that specific case -, it sets some minimum price.
  
• Consider the overhead resulting from you needing to teach client the necessary skills, finding the solutions and handling some hard character buying from you. This needs your time and resources - thus, consider getting some money from consultations in that case. I think that it makes several times of difference in actual speed if your client can't get along. Consider that you might lack the communication skills - maybe you, as a programmer, haven't understood how important those are? You are selling the time of creating contract, creating some demo or prototype, managing the client - if they wont pay for that, they are likely not going to pay at all. If you don't ask money for that, they are wasting those resources of you.
  
• Consider, how much people are able to do your job; how long it would take to learn it for them (how big percentage they have of necessary skills and how good learners they are). This will also set the minimum prize (or maximum) in case that work is needed.
  
• Consider, what you get to your skillset - in case you have some goals about which tasks you should able to carry through in future, how much the new experience adds to those skills. This won't change prize so much, it changes how much you should want that job.
• Consider the general good or bad your client is going to produce with your project. In case they create some new problems to your environment, it has a prize - in case your work plays a key role in that, they have to pay you for solving those problems. You can donate somewhere etc. In case they solve some problems, you can pay them. You should give some competitive advantage to clients working for general good - they should, in fact, take the whole market (not your client alone, but all companies of that kind). Once again, think about the world, your country and your friends a bit like if they were your project - you are a co-owner of that all and you can use some simple means to keep it all on good track. For your own good.
  
• Consider the prize of source code - that has a prize, your work without source code costs less. Consider the prize of you co-owning the results, in case you have something to do with resulting code, you can invest a bit yourself. Consider if your client is licenced to sell your code to others and if you are.
  
• Consider the general good your client is willing to give you. Are they restricting you in any way? Restricting you has a prize. Are they giving you some good in addition to money? That good also has a prize and you should be willing to pay for it.
• How big is the risk? What is the risk that you can't finish in-time? This changes both prize and your willingness to take the project; make a client aware of any possible risk factor.
  

I have also read about prize calculation formulae, which takes into account, how much it would cost to combine the same thing from cheapest existing products and buying from cheapest competitors. You should not consider the competitors, who haven't enough time to take the job or who are too hard to find or relyable.

If people lived a 1000 years

Sometimes I think what it would be if people lived some 1000 years. Most people, I mean, not just the one who found some tree of life. I know some negative sides of this coin, but there are positive ones, which are strong. Lets say they don't get children each year etc.

I have thought about the following:

• Number of friends and other people in your life.
• Number of places you know well.
  
• Number of fields of interest, knowledge.
• Value of experience.
• Music and things you own.
  

And, one by one...

Number of friends

Counting firends family etc. Who is socially inactive, will go through lifetime with closest family members and few friends - I have one close relative, 28 years old, who is like that. Who is socially really active, will find one or two friends each year and meet them all often.

You can skip this part: Young people see their friends each month. Older people see their friends several times per year. Oldest people have, in case they are still active (lets take my grandmother) thousands of friends - people they know well -, who all have their children, children of children etc. Oldest people see their friends, many of them, few times per year and talk about the biggest life events, mostly, and most important things they have found out meanwhile. They still have enough memories together to be close, their children get to know each other and they have many hidden connections through that. Oldest people may know people many generations back in time and they understand, thus, many more relations between people. They also have had time to know tens of thousands of people - when total music maniacs I know might know some few thousand musicians at age 20 or 25 (when they have been aware of this world maybe from age 10), they also know few hundreds or possibly few thousands of people in their life (family, friends, friends of friends, people from schools and workplaces) and a little bit they know some people who sell food at shops, people who sell kayaks and people who repair their electric devices. They also know some well-known people - presidents, many politicians and such, which might add some more thousands. They know actors (at least few, but when you start thinking, you can recall new and new ones without an end even if you don't watch much TV, just think about movies and people in those). This is possible, that people at my age know some 10-20 thousand other people; they have met and talked with several thousands they remember. I can recall some people from food shops and supermarkets I have seen over years, someone I used to talk at some school (who I have never met afterwards, just some small talk) etc. I'm certain that total number is several thousands. After more 5 times as much time, there could be ten or twenty thousands - especially if I kept the full health and activity. And I'm not the kind of person who hangs around at parties all time - I do it few months per year, other time I'm alone and programming or being with my wife alone.

So, after 1000 years (this makes maybe 900 years of active time instead of 60) you will get 15 times more close friends and those less close friends - many of those get closer over years (with a person you see once per year you have met already 500 times after 500 years instead of 20 - that's like being together over one full year) ...this means that instead of knowing 100 people well, 100 people twice less well and 1000 people somewhat after 10 years, you might know, after 1000 years, 10 000 people well, 10 000 people twice less well and 100 000 people somewhat. From movies, television etc. you will know million if you now know ten thousands!

This is not just quantity. You will know relations between people and entities. When you see some totally different and new kind of person once per year, you know them 900 after 1000 years, you have broad circle of understanding.

Number of places

Ok, that does not need explanation. You know, how much you travel. When you meet a new place and live there a few months, you start traveling there more often, your world grows bigger. If you, for now, know 2 cities well and this is 30th year of your life - after thousand years, you might know some 40 cities as well. But that's possible you start travelling more often over years. If you know 10 cities well, you will know 400. If you travel to one place for one week twice per year and live some two months in some place in each five years - ok, calculate yourself.

Thus, you will know a lot of different places and relations between them. Earth becomes more smaller. You will know, after 1000 years, many places similarly well as you know your home city right now. That's a lot.

Number of fields of interest

People, who don't learn fast and much, still learn over time - they read some wikipedia articles each month, new needs will appear in their life and they read newspapers or watch TV. Everyone learns.

I had, for age 10, some interest in physics, math, logic and other fields. For age 20 I knew a lot about programming. I still develop myself in fields not my choice - but at the end of my life, I will probably know only few fields very well. Anyway, those fields I know in degree of 10% of professional knowledge (and there are many of those) I would know 40% when I'm 70 years old. I would have professional knowledge about 4 or 5 fields at that point in case I manage my time effectively - like programming (number of programming fields) and several related fields, which help to make my programming job more practical and effective - you know that, programming has no big value in case the program is not written being fully conscious about some real-world problems this program is supposed to solve.

After 1000 years, I would be professional (at todays standards) in some 40 or 50 fields (and that's a lot!) given that I know 4 or 5 at year 70, also for those I know some 40 or 50% professinality at year 70 (there are tens of that) I would have learned maybe 100 at professional level or just additional 90 fields in 40-50% professionality level. In each case, there would be people being professional in several hundreds fields and normal people would be professional, as much as they are now in few fields, in tens of fields. Also, what I didn't even consider - in time, you will find connections between different fields. I mean, if you know both physics and chemistry well, they have a lot in common - and actually learning one is also somewhat learning another. Learning about latin language will make you better in several other languages and learning some general math helps in finances and architecture. Thus, actually, instead of knowing so many fields, you would know just so much more about the world.

Value of experience

We make mistakes. It makes a few long years to figure out some of them and find the ultimate solutions. As we get rid of small mistakes, we get bigger challenges, responsibility in bigger things and thus do bigger mistakes. This is a normal course of life - how much responsibility one can carry. How well one can finish the task. How fast one will understand the new topic (this is a skill and it develops slowly). How much one can take feelings, matters of things and finances, normal course of life events, different things into account when making some decision. How often one will fail with things they start.

Someone, who is been here some 30 or 40 years, will always do mistakes - they can fail with project, loose job, go into conflict with wife, buy some expensive thing, which will not give what it was meant to give, create some unsuccessful company, hire someone who will fail in something, whatever. Many of those are serious things. If you are some 70 years old, you usually fail less often. If you was 1000 - you would possibly carry some things out, all the time, with really good results. Think that you will have also mentors, teachers and authors of books you read with same experience level! You have people, who have learnt five years and then simplified their knowledge so much that they could say in five sentences something, which would have taken some other 100 years to learn for you. And, still, you are also consious about some millions of details behind things in life, you can make up your own conclusions and recognize such truths when you see them. You have thousand of people to ask, you know their interests.

Music and things you own

You have listened some number of songs, some number of complex rythyms etc. You would have listened hundreds times more. You have been in hundreds of shops, chosen things you like - you would have been in many times more shops, your home would be much more better (and even if it burnt down, you would at least know, what to buy and where, who is able to provide you that). You would know, what is a quality - something, what even money can't give you.


Thus, the life would be different. Not only longer, but different.

Software development problems with time estimations

After some 10 years of commercial programming, I would like to share some observations about how some common practices in time management can fail.

I will show in this article:

• It's wishful thinking to think you can estimate your development process. Or it is not, in fact, a development process (like creating a new simple page on CMS engine is rather professional use of ready-made software).
  
• Tight deadlines might be a way to failure. They often lead to estimate project's end-time constantly to next or overnext week, which actually delays getting it ready.
  
• Loose deadlines are not a solution.
• Agile processes are hard to follow, but well-reasoned.
  

In software development in general it is very hard to estimate times exactly - this fact might seem counter-intuitive, because in many areas it's simple to do time estimation by calculating units to be built, average time spent for one unit before and the percentage of units done from total number of units. There can be several kinds of units and some additional procedures, but usually it's still possible.

In software development, it's usually not possible to estimate time. It's possible to say roughly, based on experience and some facts, how big a project is - is it more like a month or like a year. Anyway, there are no hard facts supporting even such kind of prognosis - you can't say number of units needed. Number of code lines is always more or less taken from an air, number of packages is more like a problem of dividing those code lines into categories than strong estimate about how many of them there will be.

Thus it's natural conclusion and a good practice used in iterative and incremental programming to not estimate too much. At least programmers usually can understand the fact that times are unestimatable - especially experienced programmers, who don't take those numbers taken from air too seriously not fall into numerous wishful thinking traps.

This fact is not so obvious for customer. Customer is usually a business with limited resources, competitors and strong pressure from all directions. Yet worse - customer has long tradition of setting clear deadlines and creating timely project. Customers have also standard methods of calculating cost and benefits, pros and cons. Software is a detail of some more general product or effort of customer. Having some part of bigger picture need some totally different method of risk calculation, planning and estimates is obviously very uncomfortable for them, often simply unacceptable. For clients, iterative planning with it's uncertainties is totally different paradigm - they try to fit it into their general business method and this cuts away most important parts of it.

This, now, leads to serious problems of many kinds. Usually, some general estimate of time is given and client supposes that whole functionality is ready for that time. This estimation, in practice, is rarely the worst-case scenario - it's sadly often the best-case scenario, especially in case of less experienced managers. People under pressure tend to do what pressure at that moment needs, not what would be reasonable or produce correct result in long term, because it's simple to use wishful thinking when handling long-term problems. As there is no middle way - you cant make deadlines partially fixed so easily. For software developers it's also clear that when they set some deadline they can guarantee, some competitor will agree with shorter one - and clients usually wait a little bit more if deadline has passed, thus it's even better strategy. It might even be said that for many, solution to this problem is simply choose such deadline that they would have the smallest risks in general - risk to loose the project and risk to fail. Nontrivial projects still fail often.

Inside company and for those managers themselves this kind of decision making strategy is often not clearly worded - it's stabilized by free market method, which simply chooses those managers, who set deadlines with smallest risks. Those managers will write books explaining their reasoning and that reasoning will spread as giving best proven results. This is one line of defense, but it still raises problems inside a company, which form another set of problems raised by such timings. It's also to be noticed that even if such setting of deadlines is actually not so much agile methods - agile methods do not support setting deadlines with known resources and functionality -, it's still practiced by many, who are using agile methods. Agile methods are an effective tool for managing a lot inside a company, but they alone do not provide proven and satisfactory client relations unless for companies, who are working for very professional and experienced customers. Also, in fact, if you tell to client that this application could possibly be ready in five weeks, client will read that it's possible to get it ready in five weeks - so, they will mark to their project plan that it's five weeks plus some percentage of buffer time. They do not accept that you haven't yet written those code lines, which all take some research and many unpleasureful surprises will come on the way. Many managers seek for their perfect programmers like some alchemist might seek tree of life or formulae of success - in programming world, there are no formulas of success. If you get so much experience with some tool to code it with guaranteed time, you will compile your code into library and have no need to code it at all, then there will soon be some similar GNU library or at least something similar per each competitor. Real work is and stays research work - and well known quote from science goes that "if we knew what we are doing, it wasn't science". If we knew what we are doing, it's also not programming - and it's really hard to accept this fact in world of many people wanting guarantees and safety.

This other problem is defined as follows: finishing a project is made up from a series of clearly defined steps. Those include planning, implementing, testing, releasing. Their actual consistence is more complex than this simple linear series of few steps. Now, when you move the deadline to some time after a week, a programmer will try to fit everything into this week. Fearing to lose job or just not wanting to argue and prove, programmer uses wishful thinking to follow everything as if this deadline was possible. Some programming effort will be done in first, say, three days. This includes fixing a few obvious bugs and adding some very buggy and low-quality piece of code for each missing function. After that, a day or two is spent to test this code, which is buggy by nature. After testing, some try will be there to handover this product to client unless it's impossible to ignore the fact that it's not ready (like the case of having simply nothing on screen). If there are some bugs, like application crashing after first 10 seconds, it will be given to client saying that there are a few bugs. So the week is spent to produce some code with so low quality that searching bugs from it might take more than the code itself took, test this obviously unready thing as a whole and try to communicate to client that it's almost ready. Sadly, there will be weeks and weeks of such tactics, possibly wasting some 50% or 75% of time to absolute nonsense. It also makes some need to have many hours of unnecessary discussion, searching mistakes and blaming everyone and everything - in case of more experienced manager, there is often no direct blaming, but there is also no clear solution to the problem, actually the real problem is simply dismissed. In practice, if it's clear that a project is far from ready when deadline is there, it would be safe to at least double the time estimation - anyway, it often seems reasonable to managers to add time week by week. It does not seem to contain any big problem to demand things sooner than possible - but it's trap, demanding things to take less time than they actually take will mean that they will take more than they would have taken otherwise.

I have worked for companies, which simply do not set deadlines. This, anyway, is only possible to large companies having enough resources to take some clearly defined risks, having research units, which do the projects with very high risk (called experimental); having several contracts with different companies to create the same required functionality with different tools or methods etc. All of those are impossible for small company - small company simply will not face the fact that they are risking with their existence and playing some kind of dice. Small companies take the numbers on paper and change them until they seem to make sense from some angle and do not mean a bankruptcy. Otherwise it would be hard to keep some level of moral - or in worse cases, to keep workers from already searching for their next job. Anyway, several reasons like ambition, life needs and underestimation of necessary effort lead companies into taking such projects. Projects without a risk are often boring, small and dead-end projects. One manager told me that not setting deadlines is good for two reasons - if you set it too small, you gain nothing; if you set it too large, programmer will slow down. If you are good enough to understand, when time is used efficiently and when it's not, you are able to lead without time estimates given to programmer.

Now, there is another solution - once again, an official part of agile methods. It's to tell client that you really don't know what's ready for given time and that you need a priority list and create software based on that. You can closely cooperate with a client. Not surprisingly, even that works best with client with some experiences in software development. For beginner customer, it's hard to accept - they want their results and they want to know, they don't want some company, who does not know how to get results and does some research and learning in process. They want a product. They can buy multimillion-dollar worth of effort from shop as Windows, they can get Linux for free in a few hours - and now, someone is going to ask such sum from some simple widget totally lost into richness of their desktop? And says that this will be a research effort? Clients won't want to create a priority lists or live with uncertainties. Anyway, if you can make it clear that a priority list is needed, you will face another problem - it's actually really hard to create a good priority list. I have personally worked on software for quite a while and still learning, how to prioritize tasks. Most people have no way to prioritize tasks in their life. Another problem with that - you as a software developer can actually imagine new features, customer often does it very vaguely, they have to see and touch things to say how important they are and are they correctly done at all. So, in most cases those decisions are actually mostly done by programming company. That's some of the places where the "good communication skills" needed by many CV-s come into play. But first you have to know, what you want to communicate.

As a conclusion - it's hard to get around the current accepted methodologies, but it's also hard to get into them or make them clear to customers. As each day makes some new things clear about the software you are developing, you must make some new decisions each day - to continue, to stop, to re-evaluate or reprioritize. To tell client that some estimate was wrong as soon as it gets clear, which must be tactically well thought-through. To make some painful decisions and observations - some of those mistakes might be avoided by facing the truth, facing the incompleteness of this truth and doing the best in uncertainties. Some can be avoided by choosing simpler projects and going in smaller steps - but it is also well-known fact that big results are usually achieved by taking big risks. In total sum, it produces a few really successful companies and when looking one-by-one, it produces a lot of failures. Hopefully to learn from them.