Completely agree with the premise of this article. I'd even put communication slightly ahead of technical aptitude in the skills required to freelance.
I've just seen so many freelancers fall on their face because they built out what they envisioned as "done" rather than what the client actually wanted.
It's actually how I lost my first client. It was a two week Rails/Angular contract and I was focused on things such as clean code, contributing to OSS, and putting in tests. At the end of the contract the CEO said it wasn't going to work out.
I asked for a quick call before we parted and he revealed to me that he went with a consultant because he wanted to someone to know exactly what he wanted done and for them to just finish it independently.
It sucked failing like that for my first client after full time work but I'd rank it as my number one lesson in independent work.
Lean how to sell. When I was in college I got frustrated at not having software dev opportunities and only opportunities working at the mall (I went to college right after the dot com bubble). This curse ended up becoming a blessing because I learned how to empathize with what people wanted and what they were trying to accomplish.
A lot of freelancing is just being able to sell yourself. When you find a lead you have to convince them (aka sell to them) that you won't run away with their money and are trustworthy enough to finish what they asked. Each week/day/month you have to do a smaller version of this sale to convince them to continue to stick with you and pay you. Even at the end of the project you have to convince them (aka sell to them) that they should provide positive reviews for you.
Aside from selling you've got to be sure you deliver on time and perform the work asked. You'd be surprised how much of freelancing is more about soft skills (listening, empathy, communicating, saying no, etc) than technical skills.
If have any more questions don't hesitate to reach out to me at ryan at challengeacceptedhq.com
I write a newsletter on freelancing but have taken a couple months break to wrap up my book: The 7 Recurring Revenue Recipes for Freelancers.
I second this. Well, the part about the soft skills. Of course you need to be a good web developer, but typically you won't get judged by your uber development skills. (Depends on your client though.)
Clients usually come to you (or you go to them, but preferably the first) because they are not knowledgable in the part where you specialize in. But in order to prove (show value) that you are a good web developer, you actually have to be a good salesman.
You can start dropping HTML, CSS, Frameworks, Libraries, Angular, React, Ruby, Python, Symfony, Django, Hibernate or Spring on them, it does not tell them a thing.
And once you got the gig, depending on the client, you will have to reassure them on a daily/weekly/monthly basis everything is on track so they keep believing in you.
Furthermore, in order to get some quality leads, you will have to get your name out there. I started at an early age as well, doing websites for family members and small companies in my community for a bargain. Doing so I got some exposure, got more requests and slowly raised my prices.
This is how i'm doing it and i see it's slowly working out ( creating websites and etc..). Still not expensive, so you can contact me for the next 3 months or so if you need anything ;) - some waiting time depending on your needs / how busy it is for me though.
Stay away from "doing something for big companies"... I have created a HackerNews clone without any success and a time tracking app in AngularJS for 2 big companies... They let me down bigtime and lost a lot of time ( = money) because of that -> they won't help in publicity.
Also created www.ledenboek.be - a member management application, before i found out that sporting clubs don't have money in Belgium... ( it does work great though).
I'd do it all again any time (although you should have some patience though... Not all your friends/acquintances want a website / app right now... ). I'm releasing a website tomorrow, working on one right now and got a new request for a website today. So that's 3 websites in 1.5 weeks without any publicity. Be fair to everyone, be honest also! ( don't try to cover things up, if something is hard / difficult to do. Give them an alternative). They understand if you do something a different way, if it saves a lot of time. When you notice someone isn't "communicating", but just rammeling what they want without any discussion. Stay away from those clients, they think everything is easy peasy.
When someone says they want this or that. Ask them why they want it... Some people don't know IT and give a "bad solution". If you create it, they won't be happy, because they don't realize their solution is bad! Talk to the client and discuss.
PS. And i still haven't asked my brother ( who totally needs a website, because his current one is lame for a clothing store :P ). I'm delivering a website for a collegue of him tomorrow (as mentioned). So he'll hear about it on his own work ( his girlfriend has the clothing store)..
Know how the world works, people talk - i recreated a website for a "student club" in the neighboorhood for a bargain. They'll know me in the future ;)
If you're good / honest / fair, people will come to you. Raise your prices when you have too much work.
Don't be afraid to share knowledge / they'll remember you as the guy who can help them.
If you know someone who has a problem, if one of you're clients has the solution. Redirect them (or introduce them), say something particular so your old client will know you referred him ( like one of my clients is creating an airplane, i always mention that... It is an extreme example though :P - if you don't believe me : https://www.youtube.com/watch?v=su1RCCxCMEs , that's the guy)
I wouldn't do odesk / elance / whatever... You have less competition in your neigboorhood and you won't have to drop your prices under the hourly wage. Talk about what you do, there are always opportunities if you LIKE what you do.
And at last, LIKE what you do. If you wouldn't do it for more then a year, then think about something else.
A lot of salary negotiation and asking comes down to preparation.
It's terrifying to ask for one the first time but it's a natural part of employment. The basic principal behind hiring an employee is that they will become a financial net positive for the business eventually.
As an employee you can figure out how you affect the bottom line. It may take some imagination but you can come up with a ball park figure. In a larger corporation this may be a little tougher but with some digging you can come up with an idea whether you've become a net positive.
At the point you've become a net positive everything you make the company beyond your salary goes to profit or your bonus. If you're really good at your job then a lot of it is going to be going to profit. This is the point where you should ask for a raise.
Again it will be nerve racking but if you go in knowing how you affect the business's bottom line your raise will be justified.
I'd also suggest walking in with knowledge regarding how much people with similar job responsibilities make. This can be found on salary look up sites. A quick google search pointed me out to payscale.com and indeed.com
Great copy! My only issue is with the "How I Can Fix Your SQL Server Woes". Everything prior is the right level on the ladder of abstraction. This section needs to be more specific though since it is the last area besides the testimonials to handle potential client objections.
It needs to have actual use cases where your Dad's expertise helped these businesses. You can think of it as the bullet points in a resume. It may also help to include some kind of case study that formalizes your Dad's offering.
Speaking of copy, i would rephrase the sentence at very end: "Stanley developed a reporting utility to analyze and uncover possible issues with future clients before they became a problem."
... who became a problem? the future client? (or their data) :)
Also, whole page is 1.5MB, 1.3mb of that is a photo of subway rails on top which, while cute, adds zero value. Consider compressing or replacing that.
First I just have to say this was titled "How I launched a productized consulting service in 2 days that brought $15,450 worth of work in the first month" but that was a little long for HN :)
There are just a ton of things to learn from this article. I'm not sure if I can cover them all but I'll try
> freelancing service with a fixed length, scope, and price
This negates a ton of the pains of freelancing. You wouldn't have to go through a ton of contract negotiating on price and work delivered because everything is fixed a clearly define. You shouldn't have to worry about going past the end date of the engagement since you're offering a productized consulting engagement which you're an expert at.
What if anything falls out beyond what's defined in the scope and end date? Just define a traditional MSA and SOW. The process should be a lot easier since you've already established trust with the client which is usually what 99% of contract agreements are all about (not a real statistic).
> Announce LPIAD like a product
This is what I found particularly fascinating. This service can be launched. And by launching you outreach to thousands of potential customers you couldn't reach before. That's the ultimate cold call!
It's never too late to switch or alter the direction of your profession. Plus you're asking for help which means you're moving in the right direction.
It sounds like you're at a bit of a crossroads. The first thing I'd suggest is to pick one thing and stick with it. Stop the learning.
If you want to get into programming and develop your portfolio the following is what I'd suggest
1. Create a github account.
2. Find a project that interests you. I'd look at this thread from the other day on what OSS projects need the most help with documentation for projects https://news.ycombinator.com/item?id=8551624
2a. As you're looking through projects, look for ones that have maintainers who show they welcome contributions and are willing to go the extra mile with communication. The way to figure this out is to look at past pull requests and closed issues.
5. Every time you learn something write about it and PUBLISH it
All this advice is applicable to working on two main things 1) Figuring out if you really want a career in programming 2) working on your weakness, which is communication in English. If you have any questions or want to talk about better next steps feel free to contact me. My twitter handle is in my profile.
Thanks, sounds like a very good advice. But perhaps documentation is a no so appealing endeavor.
Another weakness of mine is that whatever I do I want to be paid in advance. I just don't see a quick ROI from working on documentation but I may be wrong.
You need to stop thinking of them as 'coders'. When you think of them that way, you're putting them in a box and limiting them.
Instead consider them to be a team of people. As you said, each of them are at different stages in their career in programming. You need to understand this and sympathize with them and their code. This takes time and effort on your part to help lead the way.
You say that you review the commits now and then and find some of these issues, but do you bring them up? Do you show them how the code can look and read better?
If you do, make this a process and act as the person approving pull requests for the first several weeks. Then formalize this process and delegate this job to the next person who you feel writes high quality code.
Again a SHORT guide or book will not turn around the quality of your codebase and the team working on it. If you're interested in better code, invest in your team. Send them to conferences, give them a budget to spend on books, have book clubs and lunch and learns. Invest in the process of improving the skills of your team.
This 100%, but also OP says due to the nature of the timeline of the project he cannot review all of the commits, this leads me to ask: what are your developers' timelines for delivering work like? Equally important, what do they feel like their timelines are like?
It's really easy to write problematic code if you're being pushed to crank out work fast, all the time. The more stress and tighter the deadlines the more easily correctable problems you are going to see. Other than that you have to assess whether your team believes the errors you see are actual errors.
You're very right about the coders bit - I guess it was more an issue of framing it. I've corrected it now.
I do bring the issues up - but usually end up being really frustrated because I assume that these things should be obvious. A lot of the comments in this thread are forcing me to reflect though, and realize that I didnt "know" those things out of the box either - but learned them by seeing others' good code and learning from that or because someone was patient enough to walk my through my mistakes (of which I certainly still make many).
While a pull-request based system would be ideal - it's the timeline and the scope of work that has us a little bit stuck with setting up such a new process.
My key takeaways from this thread would be though that I should certainly do more of the code-reviewing & maybe even get some of the team more involved in code-reviews.
Really appreciate the tremendous feedback here and it makes me realize again why I end up spending so much time on HN - there's just so much to be learned here from some truly helpful folks!
I'm glad that you've gotten so many takeaways but be very mindful of this. As you've said you didn't see a lot of these things when you just started out. It's through experience that things became obvious.
It'll take time but if you focus on teaching and improving your team you will get there.
It's easy to tell when a manager thinks of you as a "headcount", and it definitely doesn't inspire hard work or quality work.
In the process of connecting with your team as people it should become much more obvious what they need to improve. Sometimes it's encouragement and building confidence (especially for inexperienced devs). Sometimes it's asking questions about what they're trying to do. Also, if you have trust with your team, then offering suggestions for improvement and constructive criticism will be more well received.
The most important thing is to avoid them becoming defensive, and back off or move on when it does happen. It may sound like coddling, but there's a lot of psychological benefits for getting people to see their mistakes and possibly even come up with their own solutions. When people become defensive they come up with reasons to defend what they did, and are blind to the fact that there may be a better way.
This is the first things I thought when reading this question. The are not 'your coders'. They are part of your team. They are your team. You need to let them know what you need, and why you hold them to a higher standard. Teach, don't demand.
Heh... have a bad experience with lunch-n-learns at a previous gig? :)
Pretty much everything in this comment thread describes approaches that only work with the buy-in and support of upper management. If OP (or anyone else) is truly in a position where code reviews are impossible, and lunch is everyone's "one break in the day", then there is very little you can do improve code quality in that environment.
In THAT kind of environment... you slog through, get what you can onto your resume in preparation for the next job search, and don't let yourself get too emotionally attached. Support for quality has to start from the top, you really can't "grassroots" it if upper management pays only lip service or doesn't really care at all.
This all depends on the environment you're working in. When we used to do lunch and learns they were on Fridays which were blocked off for side projects.
Plus half the time we did lunches it was as a team and we always ended up talking shop.
We also welcomed free food and had other people in the community come and speak. Now if you're in a culture where it's 100% coding 9 to 5 then I'd completely agree with you.
Agree 100%. My boss has invested in Treehouse to improve code practice. We also started pair programming to help each other identify potential bugs and teach each other new ways of doing things. It reduces tech debt as well.
> what would you do when your gf/bf/wife/husband complains about it?
When my wife complains about it, I just listen. She's also a working professional who works a ton more than I do so it's usually a red flag if she brings it up. A lot of times it's not about coming up with a resolution but just trying to understand what she is frustrated with.
> So how do you handle this balance?
When I first started working remote about 10 years ago I didn't think it was an issue. It was supposed to be the dream setup.
But then I eventually had kids and started my own company and saw the lines between work/life blur. At first I told myself this was natural since it was one of the side affects of being remote but I quickly became dissatisfied with that answer. This was especially the case when I felt like I had to start choosing between time with my family and time for work.
I eventually came to realize that life stuff (i.e. family, relationships, etc.) aren't a time suck from work but a healthy constraint.
For me, success does not come from pouring every ounce of energy I have into work but from embracing the constraints of my life. I use these constraints to focus on the most important things I have to do for work so that I can get back to my family as soon as possible.
For more of a practical standpoint the following are the things I do to manage the balance (especially since my home is where I work).
