421–430 of 704 posts
I learned to lace my shoes correctly at 40+ thanks to a post on HN. I will search for the post tonight.
Earlier quoted context omitted.
All I mean is he is the person paid to do this already so it's not extra dangerous. It's like a policeman doing a citizens arrest if they spot a crime on the off hours. It's frowned upon but you know it's the same thing they do in their job.
Our HN user, mr-wendel, worked at the company, but I'm not sure they said what their job was. It might have been sysadmin, but since mr-wendel talks about snitching on a senior sysadmin directly to the CEO, it's save to say that the sysadmin did not report to mr-wendel; and I presume that mr-wendel was a lot lower an the pecking order. I don't think the senior sysadmin was paid to hide browsing from the oversight?
I am from China and I always thought I am very good at math, because I can get good grades at national Olympiad level math competitions. After I came to America, I realized that I got good grades in China because I internalized the math concepts by doing large amounts of problem sets and it was actually a very slow learning process. In college mathematics courses, I realized that some of my American classmates can gr…
Earlier quoted context omitted.
> Always write the simplest thing you can, but no simpler. I don't think so. Time and time again the client will insist on stuff like "the customer only needs a single email address/phone number" but you're going to pay for that one later if you do the simple thing and add an "email" column. Same for addresses. And a whole bunch of other stuff...you need to normalize the heck out of your DB early on, even if you don'…
Go down the simple path to start, and refactor to a more complex solution when it makes sense to do so. If experience tells you the client is definitely going to ask for it later, add a “break condition” that tells you when you need to upgrade. You can put entry points into the code - comments, interfaces - to make it easier to do the upgrade.
Earlier quoted context omitted.
(Honest question) What is the difference between this microservice architecture that gets a lot of hate here?
That's a great question. Some might say it's because of the network - that makes microservices messy and so on. But I dont think so, from what I remember plan9 (the os, successor of unix), Rob Pike wanted to make it so that there is no difference between an object being on the network or outside the network. In unix philosophy, things have the same interface, it's easy to communicate. For microservices it would be RE…
In 1993 I was interviewed for an operating job in a power plant for a major airline, assigned to their data center. At my current job, I was working in a high rise office building with sixty-six floors. The operating system computer was a JC8520, which was running a version of MS-DOS. All commands had to be typed in correctly or nothing would happen. While operating the plant, several commands had to be entered every…
>a power plant for a major airline an airline owns power plant?
[1]: https://en.wikipedia.org/wiki/Cogeneration#Industrial_CHP
Earlier quoted context omitted.
I had a colleague who was old school and loved optimising, everything he reviewed come back with tiny changes that would save fractions of a ms. His nemesis was a guy who was arguably the best coder I have ever worked with. Things come to a head in one meeting and old school said if we did things his way our code would run quicker and the response was legendary 'If we coded like you it'd run quicker because most of t…
'Optimising' for simplicity would often be a good idea, though. Optimising for speed of execution only matters some times.
Learning that some folks can produce so much value with crappy code. I've seen entire teams burn so much money by overcomplicating projects. Bikesheding about how to implement DDD, Hexagonal Architecture, design patterns, complex queues that would maybe one day be required if the company scaled 1000x, unnecessary eventual consistency that required so much machinery and man hours to keep data integrity under control.…
As a good friend of mine often says: We work in a field of people who envision themselves as artists, when all that is wanted are painters.
Learning that some folks can produce so much value with crappy code. I've seen entire teams burn so much money by overcomplicating projects. Bikesheding about how to implement DDD, Hexagonal Architecture, design patterns, complex queues that would maybe one day be required if the company scaled 1000x, unnecessary eventual consistency that required so much machinery and man hours to keep data integrity under control.…
A few years ago I worked on a system that had replaced a previous system that was like that: a bunch of microservices with multiple instances, communicating via message queues, all in the name of scalability and high availability.
The actual nonfunctional requirements? Handle between 0 and a few hundred requests per day, and it would be just fine of they get delayed a few days as well.
The best part was that the overengineered previous system actually had far more outages and delays caused by its complex deployment and data model than the simple single-instance monolith that replaced it.
Earlier quoted context omitted.
Person A spends their 8 hours playing sports, reading books and socialising Person B spends their 8 hours only playing video games I would expect Person A to be better than Person B in every notable category, except for video game skill.
> I would expect Person A to be better than Person B in every notable category, except for video game skill. Not necessarily. Person A might beat B at video games, too. Just spending time doesn't necessarily make you good at something.