This hits at the true nature of the problem which has _nothing_ to do with Redis at all (which is a fine piece of technology written by a thoughtful and conscientious creator) and has everything to do with the fact that our industry at large encourages very little thinking about the problems we are trying to solve.
Hence, fads dominate. I hate to sound so cynical but that has been my experience in every instance of commercial software development.
I spent a lot of time objectively evaluating languages for a new project I built several years ago. Elixir won out. It has now been 12 years and I still believe Elixir was the right choice for the following reasons (this list is not exhaustive):
BEAM handles concurrency better than the JVM.
Elixir threads are implemented using private memory where Clojure uses public memory.
Feel free to contradict me with personal experience, but I actually posit that (like many interesting phenomena in life), the truth is exactly the opposite. The number of people in a team expands to fill the budget allocated. That budget flows from a legible & convincing narrative told to the check-writers (internal or external) that may or may not overlap with reality.
Managers have an interest in expanding their "fiefdom" and thus push to get more and more people (either by grabbing actual work or by generating work). This is indeed how you create a "legible & convincing narrative" to increase your budget (end goal being more people, more power).
In some startup envrionments the execs may want to show growth by hiring as much as possible but that's not your typical company.
This rings so true. I noticed a consistent level-up in my abilities once I started to seek the essence of the problem. I ask myself: “I start with this information. The desired output is X. What is the essence of the data transformation that takes me from the input to X?”
When I boil down the task to its nature as a data transformation, the solution flows from my understanding of the problem, and I’ve found that my choice of tools flows transitively from there pretty easily. The problem is “isolated” from the software as you said which makes it so much easier to reason about things.
I sadly have not gotten much traction when I try and advocate for this mindset in our industry.
As an aside: It reminds me of a funny point from secondary education. Did you take AP tests in high school? If you did, you might remember as I do a consistent refrain that teachers used to beat into students preparing for the tests: “Answer the question” Over and over we heard this ad nauseam until it became second nature, whether for AP English or AP Physics - and it was good advice! Because the number one mistake students make on those exams is not actually answering the question asked, which even when couched in the most wonderful prose, results in a failing mark.
I think software engineering is often pretty similar. Even the best, most sophisticated tools will not produce a working solution if you don’t understand the problem.
> I sadly have not gotten much traction when I try and advocate for this mindset in our industry.
Yeah, I know what you mean. It's become a bit of a primary signal for how I evaluate a company's engineering culture. I've been lucky to work with some fantastic people who really get it, and I've also struggled and suffered through working with those who do not.
> Even the best, most sophisticated tools will not produce a working solution if you don’t understand the problem.
I'm sure we've all seen some awful monstrosities—or created them ourselves—that we could call a technically working solution to a given problem ... but it doesn't mean anyone wants to work on it. Keeping complexity at bay requires finding the simplest solutions that isolate essential and accidental complexity. Simplicity is hard, and it requires doing this well, constantly. It is [ahem] essential to spend the time required to isolate the problem and articulate it clearly. If you can't isolate and articulate the problem without referencing your tech stack and tooling, or your explanation gets all muddy and convoluted, you haven't actually identified the essential complexity of a problem. You're still stuck in accidental complexity territory. And that's a horrible place to be designing and architecting your software from.
It's also critical to note that over the lifetime of any piece of software, as new things come up—new bugs, new features, etc—you have to keep re-engaging the same process, and evaluating/reflecting on how new things fit (or don't!) within your existing architecture/design. Failing to do so is what drives toward infinite complexity and endless "tech debt" in poorly designed software. Well-designed software isolates and encapsulates all the accidental complexity into its own space(s), leaving open avenues to adjust and expand the software. Well-designed interfaces allow you to refactor, reshape, and grow the internals of a problem ___domain in isolation from its callers. This requires discipline from a software team—and its leadership—to take the time necessary to adjust and refactor as priors change. Such work should always be moving the needle toward greater team velocity and individual productivity.
> Did you take AP tests in high school?
Yep, sure did! I definitely remember what you're describing here.
> If you can't isolate and articulate the problem without referencing your tech stack and tooling, or your explanation gets all muddy and convoluted, you haven't actually identified the essential complexity of a problem
100%. I don't have much to add but I've really enjoyed our discussion.
I am also hacking my own tool together for exactly this reason - multi-currency is one of those things that is absolutely essential if you need it, but is often ignored by a lot of these solutions.
OP, if your motivations are largely economical, you're probably best off leveraging your existing skillset and experience. Sales is a very valuable skill, and engineering/tech, while valuable in isolation, truly shines when applied to a ___domain. Building your own product while learning how to code could propel you forward in your current field.
On the other hand, if this is something with a more intrinsic motivation behind it (which it sounds like it could be the case given your post) then it might be worth considering doing the "slow" path. Have you looked into community college courses that you might take nearby? This might allow you to work your learning into the other obligations in your life. I chose a similar path (my original background was in consulting/sales) after I realized I loved the subject of computer science. I really benefited and appreciated a more formal academic setting. Funnily enough, I discovered this love after building my own product. (Which was terribly constructed, but a great experience!)
In the end to truly achieve a high level of proficiency takes time. I'm coming up on six years and only recently feeling exceedingly competent.
Remember that no bootcamp or university "owns" the knowledge and satisfaction of programming, it's out there accessible for anyone willing to put in the time. =) You'll have to have a deep look at your motivations and decide what is best for you. For me, learning programming and computer science was one of the best things I ever did.
Looks like a great tool. Thanks for sharing. Might consider using it if I start freelancing more, as I much prefer to support other small creators than big corporate software.
I started the project a while ago. My stack is Node.js with express + postgresql + redis + s3 + sqs + puppeteer (rendering html invoices/quotes/reports to pdf) for the back. The front is a browserify app with few modules: mainly D3 for the graph (https://momo.coach/blog/tech-stack/index.html)
The proposition of replacing the layered morass of node-based tooling (node, ts-node nodemon, tsc, jest, ts-jest, webpack, BABEL, 2 incompatible module specs, UMD insanity, 3 package managers!) and the Cambrian explosion of config files that it leads to is super compelling.
The tooling situation around JavaScript is certainly my biggest pain point around it and turns a really very capable and pleasant language (ES6 + TS) into a complete chore. Here’s hoping that Bun can deliver.
It has to be a similar feeling as going from CMake to Cargo.
No disclaimer is gonna change that.