rmcastil

Interesting business concept. From their copy it seems like their goal is to remove a lot of the pains developers have associated with doing freelance. My main concerns would be

1. How much does the service cost. Is it a percentage of your rate? Is it flat?

2. What is their vetting process for clients/freelancers. They claim to "only represent the most talented designers and developers". That's quite the claim.

3. How do they provide payment protection?

I'm fine with the contract negotiation, representation, and customer relations but the other business offers need more details.

> How do you guys deliver code/value fast on the first day

I haven't been a FTE in a while but here are some of the things I do as a consultant:

1. Ask for a simpler feature. On the first day you may be given a feature to work on. As you look at the code you'll get a sense of whether it's doable in the first day versus two weeks. If its too big ask for lower hanging fruit. This shows you really care about adding value from day one.

2. If 1 doesn't work ask someone to pair with you. It can be super awkward if you're not used to it and you'll probably have to fight some impostor syndrome but the ability to be humble and ask for help is something a lot of companies/team appreciate. Just try to limit the sessions to 30 minutes to no more than an hour. You don't want your head to explode. This also provides value to a team member because it allows them to work through explaining the code as well as seeing the existing code from someone else's eyes.

3. Communicate, communicate, communicate. 1 and 2 already imply this but when people are let go because they're "not the right fit" its often because they didn't build relationships with the rest of the team. Communicate what your confused about. Communicate what your excited about. If you've already been hired, then you should already be in an environment where people are receptive to you.

4. Ask a ton of questions. What tools are everyone using? How do they feel about TDD? How does this thing work? Through your questions the rest of the team may find bugs or things that need to be refactored.

5. Document everything you were confused about. If you were confused about something in the code then most likely the next person coming onboard will be too.

> freelance with the company for a trial period

Agreed. The risk here though is that with freelancing the expectations are higher, your impact needs to be felt in week one (or even day one in some situations) or else you'll loose the contract.

Regarding delivering value, you're right its very tough if you don't know the codebase. Although, if the codebase takes two weeks to learn before you can deliver a feature that means there's a problem with their onbarding. Maybe their documentation was horrible. Maybe their project setup could have been better automated. Often times addressing these issues are ways to instantly provide value to the team. Just make sure everyone knows what your working on.

Have you ever had a client? If not then you should go with any of the above. Just prove to yourself you can get paid.

Regarding how to get a higher pay you've got to put yourself in the mind of a potential client. What do they value? Just clear communication? How much money will it cost them to use you and will your work for them return its value (ie - they paid you 10K but the investment made them 100K).

Feel free to ping me if you've got more questions.

Is scaling up or accepting a cap on your revenue your only options? How are you currently billing? Hourly/weekly? Have these rates really been maxed out?

I've been a part of and seen multiple consultancies that have crapped out because they tried to convert between a single consultant to a devshop too soon. A big reason is the thought that you can somehow avoid issues with a good run rate or savings (which is sometimes conservatively advised to have at least 30K in the bank per new hire). Don't get me wrong, cash will still come in but you will suddenly find yourself managing the quality/work, expectations, and livelihood of another person. A good first step is to hire a on shore consultant (to mitigate the possible communication gap) and see how that affects your bottom line and overall quality of life.

> You could convince them that they were the most knowledgeable person in the world

I agree. I'm just saying that the challenging part (especially for those with impostor syndrome) is actually being able to convince them they are the most knowledgeable person in the world.

To be fair to Mike he does say "Nothing is a cure all". I agree with your point though. Different people have this condition at different degrees and there is no such thing as a catch all solution. Some people need mantras and some people need medicine or whatever else it takes to help them make it day by day.

> If we want to increase the percentage of effective non-impostors, we need the experts to learn to accept their expert status.

I'd argue that a good part of what helps some of these people achieve the expert status is their impostor syndrome. It pushes them to continue to be better all the time and never be satisfied with themselves (to a fault). Challenging them to "accept their status" is like telling them to change a core part of who they are.

> Imposter syndrome is not about "fake it till you make it". Overcoming imposter syndrome is realizing that you have made it.

I'd have to disagree here. Impostor syndrome is an emotion. People overcome them in different ways. Mike's and yours suggestions are just two different solutions. The way I overcome it is by mentally preparing myself for the emotion and having a plan on how I can overcome it (ie - writing tests, working on a smaller problem, etc).

> Personally I think actual impostors are more endemic and just as likely to latch onto advice like this.

This is completely true. Except true impostors are likely to half-ass the second step.

I'm the author of the "further reading" article in the post and this is exactly how I deal with my bouts with impostor syndrome. I've been around enough "experts" to know they're just average guys/gals like the rest of us. They breath the same air and have all of the same emotions.

One thing I tell a lot of people who are getting into TDD is to focus on what you want the class's interface (AKA API) to look like. This means that you can start with the assertion and work your way backwards.

As the author alludes to this doesn't mean building out the whole architecture. For me it means just starting out with a simple case, make it pass, question whether you need to refactor or not and then move onto the next simplest case. A great example of this is Corey Haine's String Calculator https://vimeo.com/7961506

I agree that TDD is not for everyone but I've found a lot of it is because people are either taking too huge of steps or not spending enough time refactoring their code AND their tests.

In the most ideal world you should have a test suite and when something in your application breaks you should only have one test that notifies you of this. This I've found is often very far from the case.

I like the idea. I'm curious of what will be done in the four weeks. Is it pure coding or is it also R&D into the potential product's market? Will they be working on other client work in parallel or be fully dedicated to the selected product.

My point is that four weeks seems like a a lot of time to dedicate to a MVP. I've seen people bang one out in a weekend. With this kind of business proposal it would seem like a good idea to constrain the time spent on each proposal. As mgkismal suggested 1-2 weeks sounds like the sweet spot.

I've come to a similar conclusion but I tend to think of it as solving little problems with the simplest solution possible. Don't pre optimize and don't pre abstract.

This is a thought process I think you arrive at when you're running your own business or in some sort of managerial role. You start realizing the constraints (time, budget, resources, etc) involved in building software.

When we first come into the world of software we just want to write awesome code. But to truly evolve as a developer you need to start asking real questions regarding what you are building.

Are we making the budget bleed by spending 3 weeks on making the most beautiful piece of code possible for a feature when it was originally estimated to take two days? Can an open source library be used instead of us trying to build something from the ground up? How does this feature add real value to the users of this product?

As I've come to believe its always a communication (or generally human) problem rather than technical. Yet another blunder in line with the Mars Climate Orbiter and the Gimli Glider.

Compared to Linux distros 10 years ago Ubuntu makes setup/use dead simple. I remember when I first tried Linux (Slackware) many moons ago it was like an epic achievement to get it up and running. Then Ubuntu came out and it almost felt like I was cheated of the whole Linux experience. Everything seemed to just magically work which is why I think its the most widely used Linux variant today.

If any of you wonder whether you use an application everyday that still utilizes Tcl/Tk, you may be surprised (https://github.com/git/git/tree/master/git-gui/lib).

Its code is dependent on the style (CSS) and functionality (javascript) that the parent bootstrap library delivers.

I use it for all the reasons described in the article. My favorite part is the support. I've only had one hiccup in my experience and was contacted by Anthony right away.

He even indulged me when I wanted to talk shop a little bit replying to my question about their stack with the following:

"Regarding what we develop in, we have a mixture of languages. Most of what we have is in Ruby, but we also have some Erlang, some Clojure and some Python. It all depends on what is the best tool for the job."

'Who's more valuable'

Exactly. The title makes it sound as if this is some sort of binary choice. Different businesses need different pieces or backgrounds.

Ultimate passive agressive one would be "I'm not mad, just disappointed".