< Back to the archive

Like what you see? Subscribe here and get it every week in your inbox!

Issue #281 - July 28, 2024

Here are the top threads of the week, happy reading!

Top comment by keiferski

It's interesting how so many people have an aversion to being a business owner / entrepreneur, and will instead put in so much effort to optimize being a well-paid employee, instead of learning how to start and run a business.

These salaries listed are great salaries, no doubt, but they are not dramatically more than say, a guy running a successful local plumbing business. And the ceiling is limited as an employee, whereas it's virtually unlimited as a business owner.

If you aren't a shoo-in at FAANG and you want to make that kind of money, your best bet is to learn how to start and run a business. I don't mean try to launch a billion dollar social app that needs venture funding. I mean a SAAS that solves a boring problem for other businesses with money to spend.

Top comment by lnsru

My advice as a parent and electrical engineer. Buy kits. Don’t go to electrical engineering. There is nothing interesting there. Only lots of wasted time. Your son is not interested how to calculate resistor’s value in motor control circuit. Your son needs no frustration with failing printed circuit boards. He needs something spectacular what moves (and is visually appealing) and causes light errors to learn from.

My path: Chinese 3 wheel chassis, Arduino and I2C color sensor. Line follower robot to be extended to multiple color sensors. It sounds easy, but it will occupy you with your sine for few weekends. Afterwards you’ll see what part is most interesting for your son. Bigger robot, bigger processor, bigger wheels, more speed, a camera instead of color sensor. Maybe just cool paint.

Good luck with your project!

Top comment by minzak

I've spent last 8+ years working on various booking engines for a world's major travel company. From the provided information it's a bit hard to see the full requirements so I'll just mention some of the aspects I had to deal with. Managing availability isn't as straightforward as it looks on the first glance.

There are things like:

* in-advance-known closeouts

* sporadic closeouts (e.g. due to the bad weather conditions)

* sell-outs

* varying availability by date/start time

* links to partner services who can partially reduce the availability count

* allotments (availability quotas for different sellers)

* resources linked to availabilities (which is another dimension)

* the list goes on and on...

Anyway, back to the data structures.

After many iterations I've settled with using Guava's Table (yes, we use Java). There are many ways to model this, e.g. you can have start times as rows and dates as columns.

It might not sound as sexy as you'd expect but it's super easy to visualise the model in your head and read/maintain the code later.

Then you can use Guava Range functionality for dates or times and do intersections etc. Hope this helps.

Top comment by muzani

I've been developing Android since 2012. It was worse then. Still sucks now but isn't as bad. Esoteric errors are still the norm. With 10 years of experience you only have to swear a whole day when updating a library, instead of spending a week.

GPT does poorly with beginners - it's definitely something humans have advantage with AI and I expect the gap to get bigger.

I do not touch legacy projects anymore because they're always horribly broken, half the libraries no longer exist. Many of them are easier to rewrite than fix. You get weird bugs where A needs to be 1.71.0 but B needs A at 1.69.0 or 2+. Upgrading A to 2.0.1 will fix A and B but break CDEFG. Upgrading everything to max breaks switch-case, turns some of your brackets to lambdas, requires you to change your UI from XML to Kotlin, etc, etc.

If you want something to hack stuff with, I made this: https://github.com/smuzani/android-minimalist-template

Originally it was designed for AI with smaller context windows. But it works as a simplified version of our production codebase. The principle behind this is that you should have good peripheral vision and that the shape of the code resembles what it's trying to build.

Top comment by nicbou

I run allaboutberlin.com for a living. I switched from Craft CMS to a homebrew static site generator (Markdown + Jekyll) and it was a game changer.

Static sites are almost maintenance-free. They cost pennies to host. You work on your content using the tools that you love, if necessary offline. There are many excellent markdown editors and no CMS comes close. Everything is under source control and deploys with a push.

If you're used to text files and command line utilities, static site generators are a no-brainer. You probably shouldn't roll your own though.

Top comment by jmole

Think about a company like ADT - they are selling security systems, but the people who really really need security (large clients with large IT budgets) would never buy an ADT system.

So like it or not, you're going to be going door to door and helping smaller clients integrate this into their systems.

I think the right way to approach this would be to better understand the problems your clients would face when trying to integrate this kind of system, and then figure out how to solve them at scale in a way that you make customer acquisition and onboarding easier in the future.

Maybe it's things like creating base docker images for common services or OS pairings that have your stack already integrated. Maybe it's turnkey integrations with existing cloud identity providers or SSO. Maybe it's tailscale integration.

In fact tailscale is probably a good model to look at here - no large organization with an existing VPN solution is moving to tailscale, or at least weren't when they first started. But tailscale made a hard thing easy, and that's exactly what you're doing here.

Top comment by anfelor

Perhaps contrary to most people in this thread, I think you should avoid learning lenses or category theory too early. These are great tools, but they take months or even years to master and are not required to write useful code in the language.

I find Haskell very useful for my projects, but to achieve this I restrict myself to the basic subset of the language (Haskell 2010, no fancy extensions such as type families or GADTs) and use few libraries aside from the core libraries. New features and libraries always carry a high learning curve in Haskell and less popular libraries can be buggy. Instead, you will often be more productive just writing the required functionality from scratch (and it will teach you more too!).

At Jane Street, I saw my coworkers learn functional programming in just one week. (some still struggled with monads in the second week -- if that is you, I can recommend Phil's paper: https://homepages.inf.ed.ac.uk/wadler/papers/marktoberdorf/b...). If you are learning Haskell in your free time and with no one experienced to help, it will obviously take you longer. If you have questions, feel free to post on the Haskell IRC or Reddit. Just don't worry that you need to read another tutorial before getting started :)

Top comment by abofh

The snarky answer is that it's easier to be a full stack developer if your stack starts and ends with JavaScript. It's also the real answer - most webapps create value in the instant of views or clicks, so being charged solely on those metrics (even 200%) can make a certain amount of business sense, and if your business doesn't have need for redundant data stores or major backend services, you can get a lot of mileage out of a vercel based infrastructure.

I personally can't stand it, and actively work to excise it from front-end applications though _because_ it's difficult to work with it as a 'part' of your world. Like a lot of dev-experiential products/business models, their moat only exists if they can keep you "in" vercel, the moment they become just nodejs + lambda to a customer, then their value-add ceases; So they make it difficult to "grow up" out of vercel -- for many shops that's fine, it will be all they need from it, so a premium for a polished nodejs+lambda+deployment+cdn experience is worth it.

But if you're a micro-arch with backend services running on your own cloud, vercel will always be the wart in your infrastructure making everything from network policy to authentication and monitoring or tracing more difficult.

Top comment by e_i_pi_2

I think the biggest thing that I haven't seen in another comment is that companies aren't being explicitly ageist, they just want cheaper labor and younger/less experienced people are willing to work for less money. I'm sure plenty of companies would be more than happy if you said "I have decades of experience but I'll take the salary of a junior position".

Without something similar to a union or a change in laws to better incentivize pay raises, I don't see a great way out of this :/

I'd say my company is "grey-hair-friendly", but they're still hiring for way more junior roles than senior roles. I'm not sure if there are companies that explicitly don't hire junior engineers, but then you'd at least be competing against other people looking for the same salary range. Working with a recruiter might also be a good idea if they can help find companies that would be a good match

Top comment by nikolay_sivko

Take a look at Coroot [0], which stores logs in ClickHouse with configurable TTL. Its agent can discover container logs and extract repeated patterns from logs [1].

[0] https://github.com/coroot/coroot

[1] demo: https://community-demo.coroot.com/p/qcih204s/app/default:Dep...