The hard part is talking to hiring managers or potential clients about this without sounding like an idiot who doesn’t know how to put his or her shoes on the right feet. What do other people do in those situations to communicate this?
Often the most difficult situations are not complex due to the use of some advanced technology or business need - but instead because of the sheer amount of components in play that you need to understand in order to add any value.
The ramp up time just to understand WHAT components make up a given system let alone HOW they work seems to have shot through the roof over the past 5 or so years.
With once monolithic systems being broken down into distributed microservices, service meshes being widely deployed, everything-is-an-API architecture and other good things - an unfortunate side effect (when combined with seemingly growing expectations on engineers to be 'full stack') is that cognitive load has shot through the roof.
While compared to 10 years ago - it does seem like most systems have better uptime - I'm not convinced they're easier to support and aren't over-engineered most of the time.
Edit: spelling, grammar (sorry it's midnight and I'm falling asleep)
Unless your business requirements change drastically every 2-6 months, then it doesn't matter what architecture you use - you'll have to redo most of the stack in a monolith or distributed microservice arch.
Are these good things, or just fashionable things? Is optimizing for five nines, at the expense of many other metrics, ever the right choice if you're not Google? Or is it just a fad? Especially if and when the implementation is just pure blind cargo-culting?
- if you're slow and careful, you're not worth your salary
- if you're skilled and finish fast, that job was easy and not worth being paid a lot
I try to charge more because I do move pretty quickly, but I have been replaced by someone "A third of my cost" more than once. If you took the triangle for "Fast, good, cheap" and graphed the market demand for each, my gut feeling is that "Fast, cheap" is the leading demand by a long margin. To someone hiring a freelancer, "Fast, cheap" looks close enough to "Fast, Good"
Hence the advice "charge more". Never try to compete on price, it's a race to the bottom that commodifies your work, and you're competing against people able and willing to work for a pittance. Be strategic, be viewed as strategic, and price accordingly. Also, consider a hybrid with a fixed-price base (esp. w an initial "discovery" phase, priced on its own), and explicit provision for time and materials overages. Mostly, figure out what works for you, and do everything in your power to deliver value for your clients.
I say all this having used a few different models over the years but also presently engaged in a long-term (well-paying) hourly contract that's honestly been a welcome break from the sales/marketing/bizdev aspects of consulting.
Sometimes fast and cheap is the right answer. And there are devs who enjoy that role (although they often don't have the self-awareness to realize this, in my experience working with them).
There were SO MANY things to figure out, and I had no experience in Kubernetes (and only surface experience with Docker, Tilt and Helm) yet I was expected to be productive in 1-2 weeks after onboarding.
The main reason why I started taking too long in doing any tasks was that I grew more and more reluctant to ask questions. They were always answered extremely shortly and unhelpfully and left me with the impression that nobody cared to help me start becoming productive sooner. Also you were expected to hang out in a rather unofficial Mumble server the entire day if you have questions. What? Are we working remotely or are we simulating an office? Seems it was the latter.
So anyway, I took the long route and started exploring a lot while working on my first tasks.
Needless to say, this got me fired. I regret losing the very respectable salary but beyond that I am actually happy that it didn't work out.
It's like, I get it, you guys are all busy, but if you took one or two weeks to hand-hold me every day then we wouldn't have a discussion at the 4th month mark about why am I so slow and that I have to be let go.
It was rather sad because I kind of liked the guys in the team -- but they were not helpful and you were expected to wing everything yourself. Which is fine, AFTER you receive meaningful initial help. Which I never did.
Sorry for rant. Reminded me of this HN comment (disclosure: not mine) which IMO nails it: https://news.ycombinator.com/item?id=25800104
But, on topic again: I wasn't able to express that message properly some of the places I worked at. There are people who were receptive to it (it == "you need to properly onboard people even if that means some of your business-critical devs work at reduced capacity for a few weeks") when I said it in the past -- and most are receptive to it in my current job as well -- so it seems it really depends on the people themselves and/or the culture of the company.
I guess it's kind of like hiring: it's much more randomness than anything else.
My general impression after I was sacked was that the team (and the smaller company) were resisting to get their culture changed with all their might (example: sitting in a voice chat room for the entire day, seriously, we work remotely and somewhat asynchronously nowadays, so why?).
But I didn't give it much thought because in the end it didn't matter: they made up their minds without discussing with me, and even if I re-applied it would not get me anywhere.
What really got to me however was that I was fired shortly after I finally took the company's mission and challenges to heart and started working VERY hard. Just 2-3 mere weeks before I got fired. To be let go almost exactly after you muscled through a mountain of obstacles and started loving the job and the people... that definitely did hit a vulnerable spot inside of me, I admit.
> Also, I'm pretty sure I've been in that gig and it bites. I suspect you dodged a bullet even if you got grazed.
Long-term I am sure I'll think the same but in the meantime my income took a hit. Sigh.
As outlined in more detail in another sibling comment, I had a lot on my plate in my personal life during the gig and I couldn't pull through in time (in their eyes at least).
I am glad and proud that I managed to overcome literal dozens of obstacles -- most of which with tech that's extremely hard to master, with Kubernetes at the top spot -- but I still wish I could work with them again. But with some culture modifications. Which, I realize, won't ever happen. Plus most companies and teams never change their culture.
I was painfully aware that I had to put in 12+ hour working days until I show a productive output, yep. But sadly the stars aligned against me: during the same period my wife had severe depressive episodes I had to help her through, my mother almost died and me and my wife took turns "patrolling" the hospital where she was laying for days, had a huge fall out with my brother during the same time, and I finally cracked under financial and emotional pressure (not going to bore you with my life story but let's just say that the last several drops made the cup overflow). On top of that I was asked to comply with weird culture and practices that put extra pressure on me.
So I wasn't able to do what I was very keenly aware that I should do to keep the job. I am still a bit sad about it because I know for a fact that the whole thing actually started taking shape and I found my motivation and energy and desire to work on the problems in detail and with good craftsmanship... but it was too late at that time, apparently.
it's not your fault
that you were subjected to that, or that you did not match their terrible standards.
Yes, and:
> why I started taking too long in doing any tasks
I actually test my code, which makes me appear A LOT slower than my "fast" coworkers. So while I rarely do rework, my apparent "velocity" (Agile FTW) looks much worse.
I mean actual tests. Including negative tests. Which requires knowing how the system I'm changing actually works.
My last few gigs, I don't recall any one else testing their code, much less doing negative testing.
Multiple times, coworkers will discover that their code in production didn't actually work. Could never work. Ever. Like the "cache" which never updated its entries.
One of the curses of having been a QA Manager, doing actual QA & QC & Test, is I'm embarrassed when my code doesn't work. Which has become a career limiting character flaw.
And it's still under-appreciated as a skill to this day even if I got handshakes and many "good job!"-s in chats.
Unfortunately most software companies (like all companies) are based on management ego and rah rah rah. This is an infamous problem which is part of why software quality is so low.
I now ask exactly how management attributes time for bug fixes. If they aren't allocated to the person, team, and story point for the original feature, then I explain to them my story and why I won't work for them.
I've had colleagues in previous jobs that were times better than me and they got jaded by such attitude and left, leaving EVERY single manager "very surprised". But they were also kind of snarky and dismissive about it. Oh, they joy when they finally admitted 6 months later that they made a mistake by letting him quit and then the second negotiations when they wanted him back! He told them "eff you" twice in a row but eventually accepted 6-months contract... at 3x his older salary.
I feel that the under-appreciated engineers must learn to punish the companies with their absence much sooner. But yeah, a lot of programmers are rather introverted and shy and don't understand the leverage they have so sadly what we have as the status quo is pretty normal...
Ya, that's a pretty good list.
> ...not too much catering to “super stars”. 1-2 heros does not a team make, the senior people make it their job to lift everyone up. The team doesn’t obsess over their high performers.
Amen.
A team is only as fast as its slower member.
h/t The Goal, theory of constraints
Now they're established, they've got their place. That boss that they struggled under is still there and they're going to do to you exactly what he did to them. It's like hazing. Sure one of them might choose to break the cycle and take you under their wing but they're taking the risk that after you learn the ropes you'll go to their sadistic boss and stab them in the back. You know you'd never do that but this is a workplace where everyone stabs everyone else in the back so why not. Also don't think that there hasn't been someone that's already tried that and got stabbed in the back so everyone has seen it and knows what can happen so they're not going to do that.
What they were probably looking for were two things. You could take a certain amount of shit and not fight back or at least fight back but only to a limit. They wanted to know that you knew your place. The second thing is they wanted to know if they could trust you. Until they know that you're not going to go to their boss and say something like, "I have no idea what they're doing. They don't even know XYX hot new tech" you're an enemy.
Not staying there very long was probably a blessing. Working in these environments can leave some serious scars. You read about stuff in history books were you think, "wow, how can someone be so angry that they do such terrible things to other people" then you work at a place like this and you find yourself thinking, "if I came across him in the parking lot having a heart attack I'd step over the body and smile the whole ride home." Then you'll know.
I did get the general vibe that this is some kind of a rite of passage -- the unsaid message of "figure it all out by yourself or you're not worthy". I also did get the vibe they are tired and overworked (hence they needed several new people in the team). But the strongest impression was of a formerly tight-knit team of people who are now forced to work remotely and who are begrudgingly admitting they need help, and were also strongly introverted -- to make matters even worse.
That mix led to the situation described previously: I got more and more paralyzed and hesitant to ask for help as time went by, and my daily efficiency dropped to almost zero.
The thing that hurt me was how annoyed the team acted when I asked every question. One nasty (but pretty normal) response was "read Tilt docs" and it really didn't help me when it turned out that a special Python code line had to be put because my local k8s install refused to even initialize its network interfaces without much of an error indication until I drilled way down.
I did not feel any triumph when the guy I did a screen-share session with finally admitted that they might have thrown me into too deep a pit and that yeah, my setup turned out more difficult than theirs and that yeah, last they did it the cluster was smaller and easier to configure.
I never did once thought to say: "HA! TOLD YOU SO!" -- I was just very saddened.
It's easy for one to give in to negative thoughts and to second-guess themselves but discussing with people -- including yourself -- in this sub-thread did give me more clarity and showed me that it wasn't only me who was at fault.
Thank you.
For instance, when you're talking about time/effort estimates, if you include the time it's going to take you to get onboarded with a new system, this is a sign you are more professional, not less.
However, I am saying we can improve the effectiveness of the time we spend by an order of magnitude without much effort. We just need to want it. Interestingly, I also observed that solving problems without reading code leads to increased happiness, too.
Thing is, nobody wants to produce such tools for free. Plus, they'd be a huge competitive advantage so even if a company invents such a tool they're very likely to use it for their own gain and not to help the entire programming area at large.
Consider a closely related topic: source control. Nowadays, not using any form of control sounds crazy, but there was a time when that wasn't the case. What was standing in the way? A subset of working developers who just wanted to code without having to think about the task of systematically capturing a record of a codebase's history. But having a reliable, exhaustive record of changes is more useful than not having it, and the default stance today is that you need to use source control. What did it take to get here? Programmers getting over themselves and putting in upfront work to attain a level of competence where basic source control operations are natural.
The tools that the author has created and the work they're doing is in "clearly better than what many people are doing now" territory, but it's completely unworkable so long as programmers are unwilling to get over themselves and keep opting instead to just do things the way they've always done them.
I think it's economical incentives and supply/demand games above all else these days though, not so much about technical prowess (which is IMO aplenty in most teams I ever have been in). I have met some extremely intelligent lawyers and business managers and a good chunk of them are VERY KEENLY aware that most programmers are of low quality and are unwilling to change their (barely learned and never revised) ways. They know, trust me.
But they sleep better knowing there is a bigger supply pool out there because they mostly care how do they manipulate the tech worker into their agendas and objectives -- and thus [want to] view IT workers as replaceable cogs, even if we all know (them included) that this is factually untrue.
That's a huge cultural problem. Not because I feel threatened by some 20 y/o smart guy who feels like a God after two JS hackathons, no; it's mostly because the shot-callers play on people's egos. Meritocracy is still mostly a theoretical construct.
---
RE: "we need to want it bad enough", I do want it very badly both ways: (a) have intelligent AGI-level of tooling and (b) people not shoving their current hype-train ideas into a 5-year old project -- but I personally am not willing the put the work in both because both are not my job. And even if they are made my job, I am 99% sure I will not be paid enough to (1) deliver direct business value with my tech expertise, (2) mentor youngsters and (3) work on automating myself out of the job, all in parallel.
So while I do agree with you on all accounts, I think the incentives outside of our tech bubble are wildly misaligned with our interests and objectives.
And you are right in saying that it can provide a huge competitive advantage.
The only difference is that the tooling does not give you meaningful insights unless you ask it questions. Well, unless you program your questions. But, that is actually much less difficult than it appears.
A couple of such terms that I use[0] are “knowledge transfer” and “[initial or in-depth] audit”.
Typically I’d be communicating with a non-technical decision maker on the other side, and if there’s an existing codebase (or third-party systems that need integration into what I build) I may request:
1. An initial audit before I agree to the larger body of work. Audit will require access to systems in question and the ability to talk to the people in charge of or using them. Initial audit may already warrant an NDA, but whether I can accept further work will ultimately depend on the outcome of this initial audit. The deliverable of the initial audit may be a brief document or a scope/statement of work.
2. Knowledge transfer or in-depth audit. If knowledge transfer is impossible, during the previous step I’m supposed to get a good understanding as to why (does the previous owner refuse to communicate? which factors have caused this situation?), and instead of knowledge transfer allocate billable time for an in-depth audit. There would be a separate deliverable of this step as well, which would include some diagrams or documents describing the systems in question. A separate deliverable is useful both to myself and to the customer (if they choose to hire someone else to work on this), and makes it clearer what the customer is paying for.
[0] If there’re better alternatives, I’d be curious to hear (though I’m not holding my breath, responding to this thread 2 days late).
One thing that I've tried (to varying levels of success) is to use that time writing unit tests. It's visibly productive, nominally helpful, and incredibly useful in picking apart what's actually going on under the hood. The two biggest challenges I run into are managers (including engineering managers) who insist that unit tests are a waste of time and codebases that retard attempts to break things down to workable units.
For contractors too the learning curve is part of the deal. The contractors get paid by the hour when they are climbing the learning curve. Managers seem fine with it.
How long does it take to do a crossword puzzle or play a game of chess? As with everything, it depends.
And the rate of change depends on the person as much as on your internal structure, documentation, scope, etc.
I think we first have to talk about it at all. Doing that, we can learn how to optimize this part of the work quite significantly.
But, would you like to detail what specifically you find hard?
Most managers will not look into the matter too closely, because if they find no wrongdoing then it was wasted time and if they do find it then they have to spend even more time to find a new freelancer. (And possibly take a reputational hit for hiring the wrong person in the first place)