5 ms·

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 f

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.

indogooner 9y ago
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.
nine_k 9y ago
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.
- alexandercrohde 9y ago
  >>> 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.
  - closeparen 9y ago
    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.
- RJStanford 9y ago
  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.
beager 9y ago
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.
- maxxxxx 9y ago
  " 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.
  - ssamuli 9y ago
    You don’t have to measure it though to add it to your CV, instead of list of technologies used.
    - maxxxxx 9y ago
      What other value is there other than money when it comes to resume?
jrs95 9y ago
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.
ci5er 9y ago
What's wrong with Kafka? :-)

indogooner 9y ago

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.

nine_k 9y ago

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.

alexandercrohde 9y ago
>>> 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.
- closeparen 9y ago
  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.
RJStanford 9y ago
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.

beager 9y ago

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.

maxxxxx 9y ago
" 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.
- ssamuli 9y ago
  You don’t have to measure it though to add it to your CV, instead of list of technologies used.
  - maxxxxx 9y ago
    What other value is there other than money when it comes to resume?

jrs95 9y ago

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.

ci5er 9y ago

What's wrong with Kafka? :-)