Hacker News new | past | comments | ask | show | jobs | submit | anpat's favorites login

> But why is slow bad? Fast software is not always good software, but slow software is rarely able to rise to greatness. Fast software gives the user a chance to “meld” with its toolset. That is, not break flow. When the nerds upon Nerd Hill fight to the death over Vi and Emacs, it’s partly because they have such a strong affinity for the flow of the application and its meldiness. They have invested. The Tool Is Good, so they feel. Not breaking flow is an axiom of great tools.

To add some hard data to this, the “eight second rule” [1][2] is the maximum amount of time a user, on average, of a system can wait for that system to return control back to the user without the user having some other thought pop into their brain, interrupting their flow.

[1] Response Times: 3 Important Limits (2010) https://www.nngroup.com/articles/response-times-3-important-... says it’s more like ten seconds

[2] Website Response Times (2010) https://www.nngroup.com/articles/website-response-times/

[3] The Need for Speed, 23 Years Later (2020) https://www.nngroup.com/articles/the-need-for-speed/

Edit: Added reference

Edit 2: Additional reference

Edit 3: One more reference

Edit 4: I think there are still many many opportunities to improve flow in many processes. Top of my list would be keeping compile times in the single-digit seconds.


"Given the choice of anyone in the world, whom would you like to punch in the face?"

My sparring partners.

"On average, how long do you spend composing tweets before you post them? Do you realize that they don’t matter?"

I don't have a twitter account.

"Before responding to a text, do you wait a few minutes to make it seem like you’re doing something more important? Why? Answer me now."

Yes, because otherwise people unconsciously start taking you for granted.

"What would constitute a “perfect” day for you? Why do we always just go home and watch Netflix instead of doing any of that stuff?"

Being together.

"What’s your favorite song? No, it’s not. I’ve never once heard you listen to that song."

World in my eyes. She likes Depeche Mode too.

"Honestly, which one of us would you rather have die first?"

Her, so that she doesn't have to miss me.

"So you want me to be the one who becomes a burden to our children and then dies alone?"

No, I want ME to be the one who dies alone and her the one who dies loved.

"Name three things you find irritating about your partner."

Actually, we just discussed one today and are making steps to deal with it.

"Why do we even have a dishwasher if you insist on thoroughly scrubbing the dishes before putting them in? O.K., fine, I’m adding your dishwasher issue to my list of irritating things, too. So there."

This only seems to happen with American dishwashers. For whatever reason, they never manage to clean if there's visible food on the plates.

"If you could change anything about your partner’s family, what would it be?"

For her stepfather to still be alive.

"Take four minutes and tell your partner your life story in as much detail as possible. I already know that story. And I was there for that one. It didn’t happen like that."

We all remember things differently. That's half the fun :)

"Why did you send me a link to this Times article if you didn’t want us to go through the questions together?"

That's precisely why I sent it.

"Between you and your partner, who is the better gift-giver?"

Her.

"What is your most treasured memory? I was there for that one. It definitely didn’t happen like that."

Doesn't matter. She was there and that's what counts.

"What is your most horrible memory? No, “Right now, answering these questions” doesn’t count."

When she went missing and I thought I'd lost her.

"Is there something that you’ve dreamed of doing for a long time but haven’t done because you know your partner wouldn’t like it?"

Nope. We're secure enough in our relationship to do some things alone out of consideration for the other.

"Don’t pin that on me. You know we don’t have to do everything together, right?"

Absolutely.

"What do you want to do for dinner?"

Stay home, eat Kartoffelgratin, and play Killing Floor 2 together.

"If you knew we were getting dinner tonight, why would you eat a cupcake at five? All I’ve had to eat today is a cup of soup and, like, eight almonds."

Oops, sorry.

"Take turns going to the bathroom with nothing but a thin, not at all soundproof door separating you from your partner. Just sit there and hear it all."

Sure, that's our daily life anyway.

"What do you want to watch tonight?"

Das Boot. One more episode till end of season!

"Are you going to fall asleep in the middle of the episode again?"

Maybe. She might also. Some episodes we've watched halfway through 5 times :P

"I’m not the one making us answer these questions. Do you want to stop?"

Nope, I'm good.

"Do you not think our relationship is strong enough to handle these questions?"

Yup.

"How do you feel about your partner’s relationship with his or her mother?"

It's been strengthening over the years, and that's good.

"Oh, like your mother is so much better?"

She gave birth to me, gracing God's earth with me. So yeah :)

"Share a tube of toothpaste with your partner."

Sure.

"Why are you not squeezing from the bottom? Are you a monster?"

Because I like to torment her.

"Tell your partner which celebrities you find attractive."

I'm not good at knowing who people are so I can't name names, but in general 90% of celebrities are attractive by design, and don't look that way in real life.

"Why do none of those celebrities look anything like me?"

Because they spend 100k a year on it and have a team of professional photographers and photoshoppers at their service to bend reality.

"Rent a car with your partner and drive while he or she gives directions."

That's what we normally do. Driver side driver, passenger side navigator.

"How am I supposed to get across four lanes in two seconds? You have to tell me the exit earlier."

Oops, sorry.

"Tell your partner something that you like about him or her. Try to think of something. Anything."

She's the most loyal, loving and caring person I've ever met. She even gives dosh away in KF2 to newcomers when she's medic in the early waves!

"Given the choice of anyone in the world, whom would you like to punch in the face?"

My sparring partners.


I use ontologies like https://webprotege.stanford.edu

Fewer descriptive words, more structure.

A company ontology has three top level categories: Parties(internal, external), Metrics(Platform, SaaS), and CompanyStructure which has links to things like cap table, incorporation artifacts, org chart, accounts, etc.

The metrics piece is useful because it provides north star metrics for a SaaS business, and then performance ones for the Platform itself. All features roll up into these, and then their git codebases are linked from there.

If your features don't drive your metrics, you're just in the custom dev business.

I use it personally, but it's a bit dominating to have an umbrella framework that encapsulates what people think is their special contribution.


I've come to realize the problem with Java is not the programmers. Most of the strategies they want to use are legitimate improvements in flexibility, and in other languages they do make the source code smaller. Java is simply a poor vehicle.

Java forces programmers to choose a point on the spectrum of "more flexibility" <-> "smaller program size". In languages like Lisp, by contrast, the more generic a function is, the smaller it is. When I choose to make a function less flexible (i.e., making it more specific to improve performance), it gets longer. The spectrum in Lisp is "more flexibility + smaller program size" <-> "more performance + larger program size", and that's almost always an easy choice to make. Every function and macro in core.clj, for example, is impressively concise.

When I write Java, I tend to go for simple first, and then have to rewrite everything 20 times as I discover what axes of flexibility I need. In Lisp, I tend to write a function once in the simplest possible way, and then re-use it in its original form forever. It's already at max-simplicity and max-conciseness by default. Except in the rare case where it ends up being a bottleneck, it's done.

What I want above all is "more maintainable". In Java, the two factors that drive this are on opposite ends of the spectrum. There's no ideal design, and whatever point I pick today will turn out to be the wrong choice later.


Let's not, actually.

Let's start with you reading (and demonstrating to me a core competence of) the basic texts of philosophy leading up to deconstruction-- in this case, that would be Husserl, Heidegger, Hegel, Nietzsche, Freud and Levinas.

When you have those six down, I'd be happy to explain deconstruction to you.


Oh man, I know exactly what you are going through. I had the "3am chest squeezes" for a long time, I'd wake up thinking I should be working harding doing SOMETHING to make SOMETHING happen. And realizing that even if I worked 80 hours a week there were somethings I could not budge. It's like with coding if you put in a lot of effort you can fix things, but with management there is no feedback loop like that. It took me a long time to get used to.

Delegation is necessary but it hard the first few times. It takes a lot of getting used to because very few people are going to do things up to your standards (some will do >= you which is awesome). Note that eventually these feelings went away...until I got promoted and then they came back again: 3am chest squeezes and a sense of "I don't know what the fuck I'm doing again and no matter how hard I work the needle doesn't move."

Over the years I realized this is just a side effect of new challenges with increased responsibility. You (YOU) are a natural problem solver and it takes MONTHS to come up to speed so don't beat yourself up. You will solve the problems and invent your own systems.

Finding mentors is hard, but I found some through Meetup.com of all places (bay area, austin, and portland are my haunts). Note: they're not all older than me, but they have had similar experiences. Mentors can be younger than you. And mostly they don't have specific help because at this level techniques aren't really transferrable from person to person... my startup founder friends just remind me I'm not a phony fuckup. And that matters.

Welcome to being a grown up!!! It'll never be quite as fun as being a 20-something hacking code 80 hours a week for years on end, but there are new things to enjoy with age!!! (Confession: I still write shell scripts to procrastinate because it makes me feel like I've accomplished something.)

Good luck! This sounds cliche, but remember YOU REALLY CAN DO IT, don't set the bar impossibly high. You've got the right attitude with your realization in the sentence to last. Just trust that your knack for problem solving as a coder will cause your brain to inevitably figure out creative solutions to your current problems.


So many times i have seen coders "promoted" to managing roles. It actually seems to be normal practice to do this because: the coder is intelligent, the coder knows whats going on technically, plus the idea that general experience is somehow related to management skill.

However the truth is if your not regularly training as a manager and consciously applying well known good management techniques then your probably not doing so well... as a manager.

As a coder you train a lot! then as a manager you should also train => proactively get training please!!

However management is a soft-skill, and coding is a hard -skill. Mistakes in management are not seen clearly to actually matter too much. Mistakes in coding clearly matter. When bad management techniques are applied (such as frequently requesting changes, imposing bad deadlines, not actually planning ....) then the outcome: bad or wrong code, missing deadlines will be seen as an issue with the coder and not the management. How many coders are being turned over before....

an anecdote:

When the emperor napoleon marched back to Paris after his 5 month sprint through the Russian winter, he was able to return as Emperor and remain as Emperor without too much trouble when considering the scale of the disaster, he was then able to then raise another Army and start a new series of campaigns.

:) https://www.edwardtufte.com/tufte/posters


Remember, the rationale for the existence of patents is to "promote the Progress of Science and useful Arts", not to reward people with monopolies, which is the mechanism.

This is one of several related reasons why I hate the term "intellectual property". Ideas are not property, and shoving them into a property-rights framework and thinking of them as such leads to all sorts of perverse results.


This is a great post and so spot on. At some point in my career my 'review prep' (which was the time I spent working on my own evaluation of my year at a company) became answering the question, "Do I still want to work here?" I categorize my 'review' in four sections (which are each rated at one of five levels, needs improvement, sometimes meets expectations, meets expectations, sometimes exceeds expectations, or consistently exceeds expectations)

I start by reviewing how I'm being managed, I expect someone managing me to be clear in their expectations of my work product, provide resources when I have identified the need to complete jobs, can clearly articulate the problem I am expected to be solving, and can clearly articulate the criteria by which the solution will be evaluated.

Second I review my co-workers, using a three axis evaluation, can I trust what they say to be accurate/honest, can I count on them to meet their commitments, and are they willing to teach me when I don't understand something and conversely learn when their is something they do not know.

Third I review what level of support do I get to do my job. Am I provided with a workspace where I can get work done? Do have have the equipment I need to do what is being asked? Is my commute conducive to the hours required? And finally and most important, does this job allow me to balance work obligations and non-work obligations?

Fourth I review whether or not the company mission, ethics, and culture is still one that I wish to be a part of. Am I proud of the company's mission? Do I believe that the leadership will make ethical calls even if doing so would mean less profit margin? Can I relate to and am I compatible with the values that my co-workers espouse and the actions they take? (this is the "company culture" theme, is it still a company that fits me culturally)

A company that receives lower than a 3.0 rating I put on a 90 day "company improvement plan" (CIP). I bring issues to the leadership who are in a position to address the situations that I've found wanting and try to secure their commitment to change. If after 90 days they haven't been able to (if they choose not to they're done right away), then I "fire" the company and work to process my exit as expeditiously as possible.


5±3, if I remember right, but of indeterminate size. You can expand it to a couple dozen by moving up and down abstraction levels.

An exercise: I have 36 letters for you to memorize, in order and without mistakes: "The quick brown fox jumped over the lazy dog"

The sentence as a whole only uses 1 of those memory slots. As necessary, you can jump down one abstraction level to get 9 words, or again on a word-by-word basis to get the full 36 letters.

Code is the same. For example, use multiple slots to understand loop conditions, then file it away in a single slot as the whole conceptual loop. Use multiple slots to understand the loop body, in the context of one element; file it away as well. Combine them into a one-slot conceptual understanding of the whole loop. So on and so forth.

As you work with the conceptual models, you'll also end up with them in long-term memory and not have to do this reconstruction each time.

This pattern can continue indefinitely, with conceptual models of whole packages and systems. Most will do it unconsciously at that level as they become familiar with a codebase, but it works at every level, and is the basis of "running code in your head".


Celestia[0][1] can just about do it. In principle, it can show you what you'd see from any point in space. In practice, it's limited by the data it has (for stars, it uses the Hipparcos Catalogue, which only contains ~ 100,000 stars of the ~ 250 billion that are in the Milky Way) and displays the Milky Way, outside our "immediate" neighbourhood (i.e. several hundred light years), as just a set of amorphous blobs. Hence you can visualise the Milky Way as seen from the edge of the galaxy, but it'll be rather blurry. (It also obviously doesn't include the newly discovered warped shape.)

Edit: For this purpose, I think that this "Chrome Experiment"[2], might be better.

Also see "Gaia Sky"[3] which I haven't tried, but which looks really interesting and may well do what you want.

[0] https://celestia.space/

[1] https://en.wikipedia.org/wiki/Celestia

[2] https://experiments.withgoogle.com/100000-stars

[3] http://sci.esa.int/gaia/60036-gaia-data-release-2-virtual-re...


The hardest part of working with really smart people is that they can rationalize pretty much anything. Worse still, if they have been on the project for years and you’re the new guy, you’re working from a deficit of knowledge and they’ve had plenty of time to cook up a “coherent but wrong” model of the universe. The only thing that saves a group like that is humility. Trying to see the system through the eyes of the new person helps loads. I call people out for complaining about “having to” train a new guy. It’s “getting to”, man. Take advantage of the opportunity.

The first time I worked with a stable group where everyone was a smart as me, even the old new guy with a massive inferiority complex who managed to sneak one really profound comment into every meeting, there was a lack of humility on everybody’s part and things did not go well. Planning meetings were exhausting because you could get them to bash their own old work but couldn’t get them to admit to needing to change process at all. I should have quit, but I had a string of experiences with persistence paying off and I had not been beaten yet. That was the first time, and my current employer the second (I should probably quit here, too).

Cognitive dissonance is at its absolute worst in the head of a scary-smart person.


What author misses is that multi-repo is also not dumbass proof. Our team of about 60 people owned about 5-6 git repos that compiled into one SO. Every simple bug fix required multiple diffs to multiple repos.

The real argument that the author is making is that worse is better. Monorepo requires good tooling and a disciplined team. Multi-repo is worse but it is easier to manage when dealing with inexperienced programmers who want to have their own repo for their shiny little microservice.

IMO, the difference is that multi-repo has limitations and mono-repo has challenges. You will never get atomic commits and precise versioning in multi-repo. With mono-repo, there are a lot of challenges that can be solved with good engineering.


I think of software developers having multiple qualities:

- coolness (cooperation, proactiveness, professionalism)

- carefulness

- integrity (ethics)

- morale

- cadence (speed) of work

- skills competencies (matrix)

- grit (badassery)

- estimated time to completion multiplier


Two related books that say much the same:

"The Depression Cure: The 6-Step Program to Beat Depression without Drugs" https://www.goodreads.com/book/show/6446928-the-depression-c... "Most Americans work long hours, eat on the fly, and lead increasingly sedentary, isolated lives. Alongside this lifestyle, depression rates have skyrocketed: approximately 1 in 4 Americans will suffer from major depression at some point in their lives. Where have we gone wrong? Dr. Stephen Ilardi sheds light on our current predicament and reminds us: our bodies were never designed for the sleep-deprived, poorly nourished, frenzied pace of twenty-first century life. In fact, our genes have changed very little since the days of our hunter-gatherer ancestors and are still building, in effect, Stone Age bodies. Herein lies the key to breaking the cycle of depression. Inspired by the extraordinary resilience of aboriginal groups like the Kaluli of Papua New Guinea (who rarely suffer from depression), Dr. Ilardi prescribes an easy-to-follow, clinically proven program that harks back to what our bodies were originally made for-and need. Here you can find the road back to lasting health by integrating the following 6 elements into your life: an omega-3 rich diet; exercise; plenty of natural sunlight; ample sleep; social connections; and participation in meaningful tasks that leave little time for negative thoughts-all things that our ancestors had in abundance.Already, The Depression Cure program has delivered dramatic results, helping even those who have failed to respond to traditional medications. Interweaving the stories of many who have fought-and won-the battle against this debilitating illness, this groundbreaking book can illuminate the path to lifting the fog once and for all for you or a loved one."

"The Blue Zones: Lessons for Living Longer From the People Who've Lived the Longest" https://www.bluezones.com/2016/11/power-9/ "To answer the question [of why some people live longer than others], we teamed up with National Geographic to find the world’s longest-lived people and study them. We knew most of the answers lied within their lifestyle and environment. (The Danish Twin Study established that only about 20% of how long the average person lives is determined by genes.) Then we worked with a team of demographers to find pockets of people around the world with the highest life expectancy, or with the highest proportions of people who reach age 100. ... We then assembled a team of medical researchers, anthropologists, demographers, and epidemiologists to search for evidence-based common denominators among all places. We found nine:

  Move Naturally ...
  Purpose ...
  Down Shift ...
  80% Rule ...
  Plant Slant ...
  Wine @ 5 ...
  Belong ...
  Loved Ones First ...
  Right Tribe ..."

You might as well have asked who among us won the lottery.

I've been struggling with this for years now; after 4 boring jobs I finally gave up even the expectation that what I'll be asked to do will be even remotely interesting (or socially useful). The chance of landing an interesting job is absolutely minuscule - the market rewards whatever it rewards at the moment, and that's where jobs flock. These days, one of the bigger thing the market rewards is writing a web-based CRUD that's 99% chrome, 1% of actual functionality. Extra points if you can get some user data to sell to adtech industry.

(My own criteria for "interesting" these days are a bit different. I'm not looking for "interesting technical problems", as in advanced CS stuff, but "interesting outcomes" - pushing the humanity forward, or alleviating a social problem for some group of people. I find it hard to even find companies that apparently work on something like that, and even then it seems they have to do lots of boring work as well.)

--

EDIT: Then again there's this topic that has been casting shadow on my happiness for a long time, that I finally seem to be able to define. Maybe our civilization has finally crushed my soul, and I noticed it just now. But it feels to me that the revealed goal of our market-driven world is to abstract everything away with money. The end-game is that as an individual, your responsibility in the society is to pick a skill - whatever skill - that makes you money, and then to use money to solve everything else with your life. It doesn't matter what you do, there is only one meaningful meta-skill - making money fall out of the system, into your bank account.

Maybe I'm just realizing something obvious that parents should have taught me when I was a kid. I don't know. Maybe it was wrong of me to seek meaning in the things one does? Maybe that approach is no longer supported by our civilization?


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: