81–90 of 137 posts
The points often lost here is that (1) this advice is aimed at startups, and (2) the whole concept of "innovation tokens." Any successful business is going to solve some problem which is probably not so obvious and that takes innovative thinking. If you're spending too much time trying to be innovative with your tech stack then you're NOT innovating on your specific difference as a business, and that hold you back (o…
The points often lost here is that (1) this advice is aimed at startups, and (2) the whole concept of "innovation tokens." Any successful business is going to solve some problem which is probably not so obvious and that takes innovative thinking. If you're spending too much time trying to be innovative with your tech stack then you're NOT innovating on your specific difference as a business, and that hold you back (o…
You can make bad technology choices today. For example, if you were using Typescript to build a mobile app, you might be tempted to use TypeORM (32k stars on GitHub, been around since 2016, widely used). If you wanted to also use transactions and concurrency then this would be a mistake, because you would quickly find that TypeORM's SQLite adapter doesn't have a connection pool or locking for transactions, and will h…
ORM is a great example of something boring yet bad.
This article gets posted a lot, but I find it a little unsatisfying. I think it’s because it’s pretty vague about what “boring” means exactly, so it’s the kind of statement most can agree with, without it actually being a very strong statement. It’s not wrong per se, don’t choose some technology posted for the first time yesterday. But if you make the choice of Java (boring) over Kotlin (shiny new), you’re possibly s…
I feel like this has been misunderstood for years. I note this paragraph: But what I’m aiming for there is not technology that’s “boring” the way CSPAN is boring. I mean that it’s boring in the sense that it’s well understood. It’s bad, but you know why it’s bad. You can list all of the main ways it will let you down. I understand F# more than I understand PHP. By the articles definition, F# is 'boring', and choosing…
Another thing to keep in mind is the size of the candidate pool. There's a lot fewer F# devs than PHP. Can make hiring a bit trickier.
It really depends on so many factors (like in house experience, really understanding the product and engineering needs, costs etc) and it does not take in consideration the "problems" of boring tech and why modern tech has tried to solve or avoid them.
The last director who mentioned that to me and built everything in django and had huge scalability issues and took about 1 year and a half to refactor a part of the app to move away from context and orm.
In my opinion the only thing that matters is "how coupled are you with the tech and how optimized for deletion and change is your code/infra"
Earlier quoted context omitted.
99.999...% of us don't work or seriously touch in AI in any way. At best you make an API call to something that might do some AI, but at that point its just another service. So for the vast majority of people doing dev work, boring choices are correct. I've had a lot of junior devs come to me with proposals for microservice architectures that can autoscale, be orchestrated, have 0 downtime with red/blue deployments,…
The first approach will be significantly cheaper if using the cloud. It allows you to use spot/ephemeral instances and scale down capacity to almost zero cost without any loss in availability. Single server in the cloud is great for dev environments and if you don't care about uptime. But given that poor uptime is toxic for customer retention only incompetent businesses would deliberately not choose to use something…
Only if you're regularly scaling down to zero (AKA too few paying customers to stay in business).
> only incompetent businesses would deliberately not choose to use something better suited.
There's a time and place for both approaches. If you're serving anywhere near the number of users needed to show a profit, spot instances are extremely expensive.
In 13 years I've seen analytics companies come and go, trends and stacks appear and disappear, and I think I've managed pretty well to keep up even with corporations with millions in founding while being myself a solo-founder and having worked on it mostly as a side project, I think this was the secret: keep the technology simple and focus on improving the current features as opposed to adding new ones. Also, be passionate about performance and simplicity: if you can make something both faster and simpler at the same time, do it now, it would save you so much time in the long run. This includes dev tooling too: like moving from webpack to parcel or vite (10s vs 1s build times, worth in the long run), or creating Gulp.JS tasks to automate manual process like uploading files, setting the file version in a readme file, and adding guards (if checks) like making sure you don't publish the dev version instead of the production one. Oh, and another secret: keep updating the libraries you are using: it's a lot easier to go from version v3 to v4 in 2019 and then v4 to v5 in 2021, then directly v3 to v5 in 2021.
PS: Fun fact, when I started working on UXWizz (called userTrack before[3]), I started with the heatmaps and session recordings, it didn't have any stats/graphs for many years. Here's a screenshot of how it looked [4], [5].
[0]: https://uxwizz.com
[1]: https://docs.uxwizz.com/about/changelog#usertrack-3.0.0-beta...
[3]: https://www.uxwizz.com/blog/rebrand-usertrack-is-now-uxwizz
[4]: https://i.snipboard.io/B6xhu7.jpg
[5]: https://www.paldesk.com/wp-content/uploads/2020/04/userTrack...
Earlier quoted context omitted.
You can make bad technology choices today. For example, if you were using Typescript to build a mobile app, you might be tempted to use TypeORM (32k stars on GitHub, been around since 2016, widely used). If you wanted to also use transactions and concurrency then this would be a mistake, because you would quickly find that TypeORM's SQLite adapter doesn't have a connection pool or locking for transactions, and will h…
Ive been increasingly disliking ORMs in general lately. After a few days of trying to identify connection leaks and poorly optimized queries in a SQLAlchemy application, I’m starting to lose my hair. I think this actually speaks well to the point of the article. We can simplify the logic a lot by using boring tech, in this case, separating the query builder logic from the connection/transaction logic. Switching from…
I think this view has to be generalized. Your budget isn't simply affecting the tech of the system, but it also affects the whole: business case, decision loop, company maturity, etc. If the business case is a true moonshot vision of epic proportions, you have to think about what tech stack can support it. In some cases, you can be fairly conservative in your tech choices. That's probably a good idea if the business case is pretty wild and ambitious since it will ground the project nicely.
However, in many cases things go hand in hand. There's often some important complex part of the business case which require complexity in the tech stack. Say, for the sake of the current spotlighted tech, the central component need a large language model. Then, that LLM is going to eat into your development effort budget quite a lot. You should probably focus on getting the core part of the system running quickly, and support it by conservative tools.
The flip side is a quite straightforward business case. Then, the competitive edge needs to come from better application of the tech, and that will often require more innovative approaches.
In summary: you need to think about where the innovation is in the project, and modify the tech choices accordingly.
