Hacker News Reader

Comment by alexandercrohde | Hacker News Reader

I guess you could attribute this to cargo-culting / resume building. It sounds like the problem is with inexperienced people wanting to (and not being stopped from) using patterns/technologies for their own sake instead of from a business-value perspective.

Part of this is a fault in business, for rewarding this type of behavior (better to have Kafka on my resume [even if the business justification was nonexistant] to get myself past the no-nothing recruiter), not to mention the "internal resume" factor of rebuilding something.

View on HN

One other way to look at this problem is to see that in most other disciplines, impactful resumes are results-oriented rather than methodology-oriented. A sales resume says how much revenue they brought on. An operations resume might state ways they created new customer value or efficiencies. A management resume talks concretely about growing a team. A Java developer’s resume says they did stuff in Java.

It shouldn’t be enough. Software engineers have a duty to identify and inventory the value they create for an employer, rather than just listing all of the tools they use. And if those engineers can’t talk about the value they create, they should take a big step back and ask if they’re actually adding value at all.

By the way, employers should share the burden of identifying software engineering value as well, and have a similar responsibility to demand an accounting of effectiveness when screening candidates. Most of the time that’s from a code test or trivia questions about some language or technology, but that still doesn’t mean you’re effective and valuable as a result.

" Software engineers have a duty to identify and inventory the value they create for an employer, rather than just listing all of the tools they use. And if those engineers can’t talk about the value they create, they should take a big step back and ask if they’re actually adding value at all."

I don't think that's realistic. If you work on some backend or infrastructure how do you measure your value? Maybe your department can do it but not the individual.

My company has a reward system for this kind of stuff. When I look at the awards they make some sense in production because they often can show direct cost reduction. But how do you measure the impact of using Jenkins? Most likely you will have to make up some BS numbers.

You don’t have to measure it though to add it to your CV, instead of list of technologies used.

What other value is there other than money when it comes to resume?

The kinds of things I look for in evaluating senior candidates are things like:

- Payments flow kept going down because of lack of reliability in our CI, so I rebuilt the job queueing system to get to 99% reliability

- Most of our business is outside of the US, so we invested in better CDN routing, got a 50% improvement in our web TTIs

- We weren’t able to deploy code often because of our monolith, so we moved to a service-oriented architecture in order to speed up development

If candidates can’t justify why a project happened and why it helped either the company or their team, then that candidate isn’t a senior engineer, they’re just someone taking marching orders.

The impact of Jenkins could be:

- Reduced the average time from pull request to deploy from 6 days to 1.5 days (efficiency gains)

- Increased the number of deploys from 1x/week to 4x/day (output gains)

- Reduced the number of production quality incidents from 36/month to 3/month (quality metrics)

- Enabled the team to ship XYZ Project 90 days earlier, which enabled an new $10 million annual revenue stream for the company.

If one has to "make up some BS numbers" then one either doesn't understand what Jenkins is good for, or doesn't understand how to identify and measure the positive benefits of Jenkins. And that's kinda my point.

edit: I should also mention that yes, it's on your employer to help you account for this as a backend/infrastructure engineer. If not, they're kinda stacking that deck against you and you should speak up!

I guess the main problem in my company is that they want to have money saved as the main input for the awards.

That's a great list in theory, but what would it really mean?

- Pull-request-to-deploy is simply a latency, not a throughput factor, and may or may not correspond to business value.

- Number of deploys (without looking at features/deploy) doesn't necessarily measure business value

- 36/month -> 3/month meaningful statistic, made up numbers

- "Ship product 90 days earlier"- You can't really objectively prove when it would have come out otherwise

Other problems include - usually the engineers are the ones who are collecting and researching these metrics so it's a conflict of interest: an engineer is never going to mention the downsides of their work in such statistics.

I'm saying if I saw those "facts" on a resume (or as a manager) I'd ignore them all; they don't sound objective at all to me but more like good sounding pseudo-truth to give a low-competence manager something to work with.

I think you'd be shocked to find that on any results-oriented resume, it's nearly impossible to objectively prove essential and sole causation of positive results. A sales rep bringing in $10mm/year in deals is a great achievement, and a hiring manager may ask about the details, but just because you needed marketing, a good product, and biz dev to warm the pipe doesn't mean that you are bullshitting when you claim those results and talk about your impact on them.

> usually the engineers are the ones who are collecting and researching these metrics so it's a conflict of interest: an engineer is never going to mention the downsides of their work in such statistics

Yeah, that's called effective self-marketing, and everyone does it.

> I'm saying if I saw those "facts" on a resume (or as a manager) I'd ignore them all; they don't sound objective at all to me but more like good sounding pseudo-truth to give a low-competence manager something to work with.

Thoroughly disagree, and I would hope as an engineer to avoid encountering hiring managers who would harbor a prejudice against engineers who can identify and speak cogently about the impact of their work.

The impact of using Jenkins should be easy to measure with metrics like "number of new version of the application released per week", "time it takes a commit to get released" or even "number of rollbacks caused by a buggy version".

With a continuous delivery pipeline setup you'll release often and the new version will work. And that's great from the business point of view.

Maybe I'm at a disadvantage for doing this, but technologies are really only a minor detail of my resume. I focused it mostly on the things I actually did. My assumption was that this would be more important to people beyond the HR/recruiter part of the hiring phase. Also I prefer not to bullshit, and making my resume some buzzword laden list of technologies is off-putting lol

> Maybe I'm at a disadvantage

You would only be at a disadvantage for that if the recruiters looking at your resume were just looking for keywords. And in many cases they are, and that's where i've seen it useful to put your concrete accomplishments in the experience portion of the resume, and put all those keywords in a gutter or in some other section (even better, put it in a word cloud for that extra street cred!)

> A management resume talks concretely about growing a team.

FWIW, this is also methodology-oriented, not results-oriented. Hiring people costs a business money. It only makes more money if they're effectively deployed and utilized. Hiring the right people is a critical task for any manager, but listing only hiring on a resume should be a huge red flag. A manager should be able to demonstrate how s/he was able to apply those hires to efficiently meet business goals.

This was an area of frustration for me at my last managerial gig. It was always a challenge to decouple headcount from influence in the minds of upper management. Too many teams just hired and hired and had very little accountability for delivering results commensurate with how they were resourced. We also had smaller teams that were delivering a ton of value to the company whose leadership was constantly marginalized because upper management didn't see them as representing as large a percentage of the engineering team.

You're absolutely right, and sorry for glossing it over there. Being able to hire is a competency, but deploying those hires for the success of the business and quantifying it is good performance.

I will say, however, that in highly competitive/politicized hiring environments, wresting away budget for hiring can be an indication of good performance, but that should be stated.

I don't think it's just that. Part of it is just that some technologies are more fun or nice to use even if they're less practical. QoL and keeping things interesting is going to be more valuable for a typical employee than doing something boring that helps them drag JIRA cards to the 'Done' column a little quicker. And ironically, it might be better for the business too just to keep engineers engaged.

Although none of that really applies to the specific things he's mentioned in this article...CQRS/Event Sourcing are pretty much a terrible idea for most people and is just going to create unnecessary complexity and misery.

Technologies like immutable log-structured storage do have advantages from the business perspective, such as lower defect rate and speed of development. Few people use technologies just to play with them when something serious is on stake (or so I hope).

OTOH not understanding business requirements before picking technologies is indeed a problem. You have to ask a lot of questions to extract the relevant info from the business side before you can make a choice. This is especially important for tacit, "obvious" assumptions that business people honestly forget to mention. (Like, water is wet, daytime sky is blue, and a kilobyte is 1024 bytes; these are facts that everybody surely knows, right?)

Another thing is that requirements constantly but slowly change. A key assumption of the architecture that was correct a year ago may be challenged due to business considerations, legislation, etc. You have to make your architecture flexible enough to allow for unexpected shifts, but this does come at a price of its being less simple, less elegant, and less error-resistant. Yes, it contradicts other business interests (less downtime, faster features rollout, smaller IT team headcount, etc). You have to strike a balance, and ideally be able to shift the balance without a major rewrite if need be.

So the problem is not in the architecture chosen, to my mind, but in the (wrong) process of choice.

>>> Few people use technologies just to play with them when something serious is on stake (or so I hope).

I wish that were true. For example, I bet the actual number is < 10% of people who use Kafka need it. There's nothing Kafka can do that SQL can't, it's a highly-specialized tool that drops 90% of database features for a performance gain. I suspect very few companies need Kafka. [Aside-- honestly, Kafka should exist as a storage engine within SQL and nothing else]

It's the whole "Mongodb is webscale" debate again.

Messaging has been a tool of enterprise architecture for 10+ years and is not so much a replacement for SQL as a way to ship information between different service backends through a small and well-defined interface, rather than the enormous coupling surface area of sharing a DB. I would expect most Kafka messages to both originate and terminate in SQL databases.

The place I often see this is in localization. If I had a $CURRENCY for every time I've seen people try to build their own translation layer rather than relying on whatever's built in to the framework they happen to be in... well, I'd probably have enough for a decent dinner, but that's still far too much.

I think this comment is a succinct view of the problem. Unfortunately there does not seem to be any easy solution to this problem.

Part of the problem is most interviewers out there do not check what the interviewee is good at. Instead they check whether the candidate knows what I know. If not, does (s)he knows the "flavor of the year" technology which I want to be used at my company.

What's wrong with Kafka? :-)

Reply on news.ycombinator.com