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?
I've been struggling on and off with this for the past few years since moving into consulting after 15~ years of permanent (platform/ops/automation) engineering roles.
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)
If your distributed microservices require several to be updated at a time for every change, are they really separate services? Isn't the entire point of a microservices architecture to reduce the cognitive load with understanding how everything in the system works? You simply need to learn endpoints, not inner-workings. Take Uber for example: post API 1 for calling a ride, post API 2 for payment data, post API 3 for reporting a problem.
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?
The amount of people excitedly telling me their 8 person startup is using microservices really upsets me. I try to tell them what a mistake it is, but they never listen. They don't know what problems microservices solve or bring. They just know "microservices = good." It gets really frustrating sometimes.
You can really shoot yourself in the foot when freelancing with this caveat. The faster you are the less you make.
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"
Yep. This is why experienced consultants tend to aim for value-based pricing / project-billing, and avoid hourly when possible. Otherwise the incentives are all kinds of screwed up, even adversarial.
At the society scale it's really hurting it seems.. every body is trying to get a chunk of the blanket and we all spend more time fighting each others than improving our lives.
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.
The hardest part of contracting is finding good customers whose priorities in that triangle align with yours.
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).
Yep, both happened to me. It seems that "he'll get into the job in a week" is a deeply ingrained assumption from many other jobs and is seamlessly transported to programming work.
On my last job -- which I do regret somewhat for losing -- I failed at meaningfully delivering that message.
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.
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.
Had similar k8s experience. Because I took time to learn how it worked, not just make believe.
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.
I have seen this before. Middle management graded teams on story points per sprint. Of course the shittiest team took that to the extreme. They had 15X the story points of everyone else. The problem is that every file edit was a story point. Every bug fixed was a story point. They shipped ridiculously buggy code constantly that cost us tons of money through lost customers. Fortunately each team owned separate service, so they had to handle the continuous calls for their crap. And yet, every time, management would scold them lightly and praise them for their hard work. The one time we had a bug that made it to production, management jumped on us. Thankfully, I left that company after a short time.
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.
This yet again proves that people just want to be shown on the basis of which criteria to judge others and once that happens they accept it as the universal truth and will not easily (more likely ever) change their views.
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...
Just remember this when you see who gets promoted, and be sure to adjust your strategy accordingly ;)
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.
Never trained for any sort of a QA but can completely relate to your mindset. I am paranoid and love to add tests. They saved the bottom of my team (and sometimes the company, in my smaller customers at least) many, many times.
And it's still under-appreciated as a skill to this day even if I got handshakes and many "good job!"-s in chats.
I wanted to let you know that you probably did nothing wrong. The people you were working for were probably just like you a few years ago and when they first arrived the guy they worked for was a prick just like they were to you. They knew nothing and their job was on the line. They probably went home every night for a year, puked their guts out and frantically did everything they could to learn as quickly as they could while during the day keeping their head down, and trying to keep the look of panic off their faces.
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.
You know what? That sounds plausible. Hurt people often pass on the pain to the newer members of any team (including families).
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.
> ...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.
If I'm imagining your experience correctly this exemplifies part of why we need to open up our culture. 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.
Well, it would be very unethical and highly illegal for me to resort to name-calling (but we can probably chat about it in private) but in short the team was a bunch of pretty hardcore guys who are very good at what they are doing but they were a part of a smaller company that got swallowed by the bigger company that hired me.
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.
Thank you for the kind words, they do mean a lot. (Still have some insecurity about losing that job, can't deny.)
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.
The only way to win at a job like this is to dive in and work twenty hour days until you show productive output. You need to over communicate and haunt those company forums. It's more the companies fault than yours. They should have paired you with an experienced employee the first few features. I bet they overhire and just use the first two months as a working interview.
Judging by one guy who left (or was fired, I don't know) while I was there, and several more from other departments then I think you are spot on -- they did seem to cast a wide net and just let some of the fish fall through. Guess it was easier that way?
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.
I'm sorry that you feel like you have to give reasons why you weren't able to work 12 hours a day. That's an unreasonable, unhealthy, and frankly disrespectful expectation from your employer whether it's explicit or hidden. I'd encourage you not to try to justify or excuse it. I can't imagine that losing the job is easy, but
it's not your fault
that you were subjected to that, or that you did not match their terrible standards.
I think the best approach is not to be apologetic about it, and just treat it as part of the job (which it is).
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.
I am not saying we should be apologetic about it at all.
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.
I completely agree but currently, the way things are, we'd need very intelligent tooling that would be able to parse an entire project and give you some meaningful insights -- in order for you to have a shorter and more impactful onboarding.
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.
The choice of what to treat as bedrock is essential to the parent's comment remark that, "We just need to want it." The notion that a person or a team should be able to use whatever development methods and architectural style they feel like coming up with at the time and then throw it into intelligent tooling to figure it out—rather than, say, spending a little more time learning another paradigm that doesn't require general artificial intelligence to be a solved problem—is something that qualifies as wanting something but still not wanting it bad enough to do anything about it.
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.
Well, we just built that platform and we made it free and open-source. Take a look at gtoolkit.com.
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.
This might seem like it’s purely about optics, but I do think being familiar with some terms to communicate the need to understand out the system you are working on as a consultant or employee while being professional about it can help a lot.
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.
I have not faced this problem. I say that there will be a learning curve to understand the product before a new developer can start fixing bugs or adding enhancements. Managers have always understood it.
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.
What is typically considered an acceptable learning cost / duration in your experience? I am not asking because I do not agree that there is a learning curve (we call it assessment), I am asking because I am curious what people expect.
There's no "duration". There's "what's the proportion of time you'll spend learning". Unless you have a very repetitive job, it will never go down to 0. It will just move towards it over time.
And the rate of change depends on the person as much as on your internal structure, documentation, scope, etc.
This depends greatly on both the Seniority of the position and the complexity of the code base in question. Generally jobs I've worked have expected it to be on the order of 1-3 months, although I've found it hasn't always taken that long in practice.
Unless you work on trivial codebases you never stop learning. The code changes faster than you can keep up. It's a constant overhead for everything you do.
You tell the managers that you will spend no time at all on figuring out the system because you are just that good. Of course, you will still need to spend some time on it. Hopefully nobody will look into it too closely, but even if they do, you can claim that that time was already part of the "fixing the problem" phase.
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)
