Lobste.rs readers are probably less likely to end up in this situation… but it’s just one failure mode of many that result from a particular root cause. Specifically, focusing on solving problems (“just hand me a problem and I’ll code a solution”), rather than taking the next step and trying to identify problems.
The advice in these CodeWithoutRules posts just seems so…trite? Maybe I’m biased but they seem to be more about getting the author’s name out there rather than giving well thought out advice. For example, the author gives an example of a company using Perl, and then goes on to say what you can do about looking tech up and talking to your manager. Is the author saying that nobody had the unnamed company has ever done this? That seems unlikely to me. IME, technology change only occurs under existential threat, not because someone thinks X will make you a bit better. The author also seems to put a lot of weight on the age and popularity of technology, not if the technology actually is better for the problem it’s solving.
In my career, I have rarely seen the advice the author gives actually work, and in the cases I can think of, it’s been due to a crisis not a marginal improvement. Experiences vary but the author doesn’t actually enumerate any real world successes they have had. Maybe that’s what bothers me about these CodingWithoutRules blog posts, they seem like Feel Good Messages, disconnected from reality. But maybe I’m just cynical.
For the record, this is how they come off to me as well. Most of the advice reads as energentic banality, akin to a corporate pep talk, sneaking in appeals to sign up for a special publication followed by decrees to “buy my book”.
I may also be cynical.
Occasionally I write blog posts about how e.g. signal and garbage collection reentrancy interact with Python threading primitives in an unfortunate way (https://codewithoutrules.com/2017/08/16/concurrency-python/).
But… I feel there’s often too much focus in programming on technical skills and too little on other, less easy to articulate skills. So mostly I try to write about those other skills. They’re harder to explain, and so I don’t always succeed at doing so, but they’re important and useful too.
With the caveats that writing is a difficult and distinct skill with many subskills, putting your writing out on the internet for peanut gallery hecklers like myself takes courage and initiative, and further that productively engaging with criticism of your work is admirable: The content of these articles seems to trend a lot more towards a first-principles-y style of communication. This works well for articles like your post on the deadlock behavior queue.Queue exhibits in some interactions with __del__, since the behavior hs a concrete, single-source cause.
Unfortunately, human interactions are a goddamn mess that don’t respond well to reasoning from first principles.
If you’re invested in writing insightful posts about dealing with imposter syndrome (“You feel like your growth has been stunted: there are all these skills you should have been learning, but you never did […]”), you may be better off looking into the effectiveness of self-esteem versus self-compassion. If instead you’d like to write about effective learning strategies (“Get your technical skills up to speed, and quickly”), a discussion and extensions of work like Iran-Nejad’s Active and dynamic self-regulation of learning processes would be more appropriate. For how to work effectively in a complex sociotechnical system, Simon Sinek and Edwards Deming and Thomas Schelling and Donella Meadows are all extremely insightful authors with much to say (particularly the late Ms. Meadows).
That is, if your intent is to write cogently and effectively about disciplines foreign to the hard logic of a turing machine, of which there certainly is a need in our industry, your work needs to exhibit more care and attention to prior art in those disciplines. Excepting that, your work at least needs hard-won anecdotes taken from (all too often painful) direct experiences that can help readers reconstruct the tools you yourself learned from those experiences. As-is CodeWithoutRules posts like the parent link are not substantive or grounded enough to do more than express a good understanding of the English language. Since you already have the courage and the practice of posting these, it’d be lovely to see the less technical posts mature into articles that are as important and useful as accessibly documenting unexpected concurrency pitfalls in Python.
I think this is a good point. I’ve nothing against theme and topics in this post – and I do not wish to discourage work in the area – but the writing is not doing it for me. As @apy stated, it sounds too much like the words of a self-help guru.
I also agree that it takes courage to put it out there.
Your argument, as I understand it: I should be writing posts based on either prior research, or empiricism. I certainly agree with that, and I have e.g. done reading on the research on learning (https://codewithoutrules.com/2016/03/19/how-learning-works/).
Let’s look at this particular post, then, and see how it does. It has the following outline:
Expanding on each:
It’s possible my full blog post didn’t do the best job of expressing this outline. But there’s no reasoning from first principles.
The flip side is, like any self-help advice, it’s much easier to bullshit than the hardcore tech stuff. I’m sure you have good intentions but writing about stuff that is easy to make up because nobody knows the difference means you have to be all the better of an author. For me, at least, and I mean this in the most constructive way possible, it’s really hard to tell if you’re some self-help guru trying to make a name off suckers or actually have insights.
The company using Perl is pretty much stuck with Perl for years to come, though I can imagine changing over a decade or so, component by component. But, they also uses many other technologies, and those have been upgraded over the years:
No doubt many other changes as well.
Those changes were all introduced by someone. Sometimes by people in charge, but I know some were introduced by lower level employees.
Sure, but were they introduced using the technique you suggest? IME, a lot of these happen because when nobody is looking someone just Does Something and now we’re stuck with it, for better or for worse.
Just because companies do change doesn’t mean they used the method you suggest. Have you successfully used the method you suggest? If so, some first hand experience would at least lend some strength to your statement, right now it just feels like your logiced your way to how this must work and wrote a blog post about it regardless of if it’s reality.
Talking to one’s manager and pointing out a problem? That did happen, yes: I believe the unit test library they used was proposed by someone to the team lead. And I’ve certainly done this many times.
This is great news!
Everyone who bought enterprise on that language now has to pay a premium, since developers are obviously harder to get!
See? I can charge 20%-200% higher on perl programming since that’s surely going to be cheaper than rewriting it!
Wait why? Where problem is defined as Technologies that are shrinking in popularity; some Google searches for “$YOURTECH popularity” can help you determine this, as can Google Trends.? Absolutely not.
I had to skip back to see the issue: The language of the author switched midway between my (the programmer; who knows things and is interested in job listings), and my company (who is responsible for a project, for business, etc).
I the programmer, individual contributor do not want to switch technologies. In fact, looking for unpopular languages and at-risk companies is a good way to become a higher earner.
I the company? This is risky advice: Enterprise software that has sunk $2m in development is going to take 10 years before the 20% increase in developer salary is going to matter, and even at that point, you haven’t factored the cost of rewriting it.
Okay, but what about “without changing languages?” i.e. the “Format.js” library example? Yes, you can try the script the author suggested, but the manager is trying to justify the costs (perhaps in her head), and you’ll make everyone’s life easier if you simply justify the costs.
This is true… under certain conditions. Some technologies just fade into oblivion too fast to make extra money, some people aren’t good at marketing themselves or finding these niches. Some old technologies end up only used in niche geographies, and if you live in wrong place you’re out of luck.
It’s a viable strategy if you consciously set out to do it, and choose a tech stack with a conservative userbase that has deep pockets. Lots of people end up there by mistake, though, and don’t know how to get out of the hole.
Agreed. I read this trope a lot, the COBOL programmer making 1000$/hour or whatever, but I rarely meet any, probably because of that niche issue.
I however meet plenty of people who spent too much effort becoming framework experts and then really struggle to adapt as technology (or fashion) moves past them.
Institutional knowledge can seem dangerous because it doesn’t have the same value to your current employer that it will have with your next one.
Is there nothing else you have to offer? If you know Symphony but not Magneto, is there nothing you can leverage? I think this happens a lot less often than we believe, and it’s really more as itamarst suggests: a marketing problem.
I’d be surprised to meet an experienced COBOL consultant who thought the grass would’ve been greener had she done C instead, and should I meet them, I don’t think their issue looks very much like a library problem.
I’m not sure I buy the geography argument either: I commute internationally for work because I have a number of very niche skills, I like where I live, and plane travel is nothing compared to my day rate.
Marketing is a real problem though. If I could get you a 30% higher salary, would you give me 15% of it?
The troubling part to me there is pushing your personal development at the expense of employer. The advice is to locate a problem (no shortage of problems in live systems, sure), and convince the management that the new tech is a suitable solution. Mind you, the management is not necessarily technical to evaluate the merits of it, and you at this point are not familiar enough with this new tech yourself to make an informed decision. This does not sound entirely honest, neither to yourself nor to your employer.
If your manager can’t decide, and you can’t decide… nothing will ever change unless you happen to have someone with pre-existing knowledge.
This is why the suggestion is to do a pilot project, not to just rip out everything and replace it. Maybe pilot project will prove this is the wrong technology, or help you understand use cases better.