Collection of comments across different forums on the internet inspired by HN: the good parts . As you can see, currently it’s empty.
- I’m a senior dev and have accepted that senior doesn’t mean all knowing. It means knowing when it’s time to RTFM, how to handle complex problems, debugging weird shit and being able to plan and lead the application development and deployment.
- But engineering principles always apply: be aware of your transport; fail gracefully; consider resource constraints; worry about encodings and malformed input and most of all, re-use existing components when appropriate.
- Once we removed the bottleneck we discovered our app’s shit. The fix was to throttle.
- Which is fine when done right… this is like explaining that the combustion engine works because dinosaurs are killing each other with rocks in the gas tank. - In response to a terrible explanation.
- This link is the correct answer. Straight from the horse’s mouth.
- The first, best piece of advice I can give you is “format your damn code”. I’m not going to apologise for telling you that your code looks like a pile of crap - it makes me want to gouge out my eyes with a rusty teaspoon, then beat myself over the head with a brick until the brain damage means I can’t remember what it looked like.
- C is to Go Like Darth Vader to Luke.
- LPT: You’re a river not a rock. You will never become ‘the real’ you. I see lots of posts that day things like “I should have it figured out by now” or “I can’t belive I used to be like that”. The truth is that good people are constantly growing and adapting. Imagine being a 40 year old that didn’t improve or adapt for 40 years. That person would suck. So don’t try and find your Final Form™ when your 30, 20 or (god forbid) 16. You’re different every second. You’re a river, not a rock.
- it is like using a fork and a knife to eat soup that suddenly became cold
- Yes. Googling all the time. Docs open all the time. Trying to remember that one function that did something like what I need. A lot of “being smart” actually consists of getting comfortable with feeling stupid .
- The kernel does what ever the fuck it wants because it’s the boss. It doesn’t want to kill its init.
- A data structure can be seen as an interface, a logical structure, a physical layout, or an encoding. When you teach them, you have to start from somewhere.
- Never say “Got it” or “OK” when someone is explaining a problem or solution and you don’t follow. It feels awkward to say “Sorry, I’m still not following. Do you mean that when…” five times in the same conversation but it is worth your time and embarrassment to come away with a correctly framed and well understood situation. Otherwise you will figure out what they meant after wasting hours/days/months solving the wrong thing.
- The economy is so good at generating value that it is somehow possible for large portions of participants to create zero or negative value.
- Lisp has been making a comeback since the 60s
- Facing the fact that ideas are ten a penny, it makes sense to see what necessary but perhaps still insufficient accessories an idea needs to prosper. In order of increasing value;
- An idea
- A good idea
- A good implementable idea
- A good implementable idea whose time has come
- An invention (the concrete verification of an idea)
- A design ( a workable invention)
- A potential product (reproducible/manufacturable design)
- A potentially profitable product
- A marketable and profitable product
- A marketable, profitable product, backed by money and good luck
- Get used to writing your code twice. If you were writing prose, almost any methodology recommends that you revise and edit your first draft, often multiple times. My first pass at an implementation is for me to understand it and solve it. If it’s a throwaway tool, that may be where it stops. If it’s committing to a common repo, I’m probably going to significantly rewrite and enhance the code at least once. If it’s the basis for a new technique/sample code, it’s going to be multiple times with feedback. Seek feedback on your code. Fresh eyes provide fresh perspective. You’ll learn a lot about yourself from others commenting on your code.
- I think I’m not going too far when I claim that such inventions are utterly over-engineer for no good reason. I had a chance to visit Google’s Mountain View office a few years ago, where they had these modern toilets that were supposed to “wipe your ass for you” by spraying water at your asshole or something similar. Never got to even try that feature as I took a pretty properly sized dump and jammed the system somehow. Unfortunately, there was no plunger at hand to unclog it, neither was there a flush button as everything was automatic. I spent 10 minutes trying fix the situtation, but had to run into a meeting eventually, so I left the big pile of shit for the next person to handle. Next day, I tried again using a different box in the toilet. Unrelated: the toilet walls and door had like 70cm of space underneath where you could almost see the junk hanging from the person sitting next to you. Very unpleasant. Anyways, the goddamn toilet did not work again. This time I had no meeting and eventually I was able to flush the shit down, but it took like 15 minutes. I wonder if they still have those toilets, but this was possibly one of the worst toilet-going experiences in my life. I felt like I was unwillingly participating in some sick experiment set up by some psycho.
- You’ll be faced with situations where your colleagues/organization expect you to implement solutions you think are not the best. Understand that “the best way” for the team or business is not necessarily the same as “the best way” for you personally or “the best way” overall. You are likely missing some context about the choice. Be mindful of reputation risks, time costs and maintenance costs involved in changing the approach.
- When you’re asked to code something you don’t agree with (including ethical issues) your options include: silently accept their approach, refuse to do their approach, propose an approach (with conversation or code) and gracefully accept the result, or find another job. Be aware that different organizations will react differently to those approaches. Under no circumstances should you fall into the trap of spending a week to convince the team to adopt a change that would save a week of costs.
- This API is in a new class of products I like to call “Deadlock as a Service”, or DaaS for short.
- After years thinking and reading RFCs and various other documents, today, I finally understood. “Simple” refers to “Network” not to “Management Protocol”! So it is a Management Protocol for Simple Networks not a Simple Protocol for Management of Networks
- The nature and exact value of knowledge work have always been dubious. After all, I might get a great idea while strolling to the grocery store. Will that count as hours worked? Paying someone for their time is easier to justify when you see someone pulling a lever. That suggests one of the reasons the subjugators of our internet economy are again asking their people to come back to the office is so that they can satisfactorily measure each worker’s butt-on-seat time.
- Instead banks have a better solution, if your bank account goes below zero, they charge you extra money to go extra below zero.
- Something about not being young anymore is that I am much more comfortable leveraging small changes consistently over time. When I was 16, the idea of doing a little bit of practicing vocal exercises each day in order to improve over time would have seemed an insurmountable challenge. I needed things to improve over the course of days or hours. (In this, I was terribly short-sighted). But now that I’m considerably older than that, I can mentally afford to allocate a little bit of time over the next six months toward achieving a goal like improving my typing, or getting better at vocal onsets. Being better at something a year or two from now feels very worthwhile, and I know I’ll be at that future me fairly quickly. It would have been better for me, of course, to have gained this ability back when I had lots of time at my disposal. But I can still have an impact because I can be the drop of water shaping the stone over time.
- Also think of dependency in software systems. If I’m dependent on openAI, who has 99% availability, and my database is 99% availability, my true availability is .99^2, which is 0.9801. Keep on adding to n, where availability^n - it accumulates. yanine on tw.
- Do you know why we use i, j, k for loop indices? Because D ijk stra!
- multiple overlapping mental models of people who started their careers in different half-decades and now pass those mental models to younger people who also started their careers in different half-decades