HN user

undergrowth54

9,952 karma
Posts1
Comments35
View on HN

Why should the non-important activities be done at all?

If I delegate something urgent and non-important to another, doesn’t that:

1. Urgently interrupt someone else?

2. Set them up to urgently ask me questions about something unimportant.

3. Burn some of their trust in me when they complete it and I’m not grateful.

?

—————

It seems the bottom two should be:

Urgent & Not Important: Drop

Non Urgent & Not Important: Maybe Play

We changed the dietary habits...

No, we allowed people to change their own dietary habits and they chose to do so.

There's no reason we couldn't change them back.

There is a reason: The probability that they would respond with violence that would spiral into a massive humanitarian crisis.

Remember that the Syrian civil war was kicked off in large part by the prices of food in the Arab world putting pressure on pre-existing fault lines.

Going back to a mostly vegetarian food supply would liberate so much land mass that you would have fewer issues feeding the world.

You're not wrong about the destination...but the path to get there matters if you want to avoid making things worse. Also, there is a massive difference between freeing up the alfalfa fields of California and the grazing lands of Afghanistan or Pakistan.

We just need to

The word "just" in this sense is a signal that you might easily be underestimating the difficulty or cost of something.

We just need to make meat cost prohibitive enough to force the majority of people to eat the majority of their meals vegetarian.

If you were talking about persuasion, this would be fine.

When you start talking about forcing people to change their habits, it is time to take a step back and get curious about those other people's perspectives. In this case, you're talking about the daily or weekly dietary habits of more than 2 billion people.

Before moving forward, you should have a clear answer to the question of how many megadeaths you are willing to cause through war and famine.

https://en.wikipedia.org/wiki/Napoleonic_Wars_casualties#Tot...

https://en.wikipedia.org/wiki/Great_Leap_Forward#Consequence...

1. Be willing to accept run of the mill advice. Your problem is not tricky—it is instead dreadfully frightening and painfully difficult.

2. Go for a walk outside while listening to Brené Brown audiobooks.

3. Talk to humans who can actually calmly listen —- Not people as disconnected as an internet forum nor someone as intertwined as a life partner.

Gnuplot is not GNU 5 years ago

But its reasonable to:

1. Conclude that its 90% likely to be what happened.

2. Not burden someone by asking a question you don’t need the answer to.

3. Disclaim credit for work you don’t lead.

ADHD-PI here. I use a version of Pomodoro technique with adaptations inspired by Leadership is Language by David Marquet and by what Prof. Andrew Huberman says about Dopamine.

Blue: Come up with my intended outcome. Set a duration from 10 to 45 minutes in proportion to my intuitive confidence that I am “on the right path”.

If I am spending too long in blue, then say the thing I’m most anxious about. State a hypothesis about it and frame my intended outcome as a test of that hypothesis.

Red: Execute at speed while still noting any surprises in a notebook.

Blue: Reflect on what I’ve produced and what I’ve learned. Notice any errors I made and think (without typing) about what led to them.

Green: 2-5 minutes meditation. Reconnect with my breath and body. Control my internal sense of time pressure.

—————————

Sidenote: I highly recommend both Leadership is Language and the Huberman Lab podcast to ADHDers and folks who just have struggles turning their intentions into action.

Worthwhile interpretations of that quote:

- "Learning a wide range of skills is useful and can let you combine them in ways others cannot."

- "You should not let your current path in life unduly limit your curiosity."

- "Sometimes life throws a curveball at you and a wide range of skills can unexpectedly be very handy."

- "There is a small subset of this list which, as an adult, you really should know how to do."

Unhealthy interpretations of that quote:

- "You are as unworthy as an insect if you specialise."

- "Time spent on one thing does not come at the cost of time spent on other things. You can manufacture time."

- "Developing a deeper understanding of a craft you're deeply curious about is not worth the time you give up learning other things."

- "A person who knows how to do all of this list of things competently has ever existed in human history."

(I assert that any person who has competently planned an invasion and died gallantly in the age where they had access to program a computer would be listed on wikipedia.)

(Also, if people didn't sometimes need specialised knowledge to make competent decisions, then central economic planning would have a hope of working.)

Goat Ops 5 years ago

If someone is frustrated by doing ongoing maintenance and about having to wake up to handle problems, I have bad news for them about farming.

Losing faith in UX 5 years ago

Part of the issue is inter-team communication and part of the problem comes from that very phrase "dumbing down". I often hear people argue for "dumbing things down" when there is an overwhelming amount of information, but that phrase:

1. Treats people's intelligence as 1-dimensional, which it is not.

2. Gives no clear direction to an engineer who is passionate about UX, recognises that humans are multidimensional, and is trying to ask about what their users really need.

You might say I'm arguing semantics, but communication matters!

Without it, you can write code at high speed, but you won't learn what direction to go in order to present information appropriately and contextually to create a rich but easy, intuitive flow.

Crony Beliefs 5 years ago

Some beliefs are facts. Some beliefs are a lens to focus on certain facts.

The problem is not that the term is imprecise. To say "We can securely check your password." would be imprecise.

The problem is that the term is _inaccurate_ because it is _overly precise_.

---------------

When you find yourself arguing over details you find pedantic, then it is a sign that you either:

A. Are failing to realize why some detail actually _does_ matter in that context.

B. Are using overly-precise terms and should see if you can "go up one abstraction layer", likely by asking "why does someone care?"

Oscillating between high distractibility and hyperfocus rather than fluidly directing attention is essentially the core symptom of ADHD.

As someone who has inattentive-subtype ADHD, I must say that this sort of pattern can result in a great deal of loneliness. It is far better to watch the course "learning how to learn" and use something like the Pomodoro technique to explicitly decide whether to be in

- focused mode

- exploratory mode

- actually relaxing and paying attention to your relationships mode

Does not solve the issue of 'meaning' and 'purpose'

For an engineer, it absolutely does.

How? By giving a broader range humans the ability to shout "This problem matters to me. Please build something to solve it" into the economy.

---------------------

Suppose it is 2013. I build a tool that helps a luxury hotel in New York do bespoke guest relations slightly better. They have customers who have money, so they have revenue, so I get revenue.

Suppose it is 2013. I build a tool that helps a food truck in Flint, Michigan run their operations. Their customers don't have money, so they don't have revenue, so I don't get revenue.

Helping people get fed and create community, or polishing a luxury experience for a very few -- Which job has more meaning and purpose?

My ego creates a tight bond between my work and my identity. Linking my self worth to how well I do my job. This then creates the need to track my performance. To keep score. Spinning up mental processes that consume valuable resources which make staying on task very difficult.

I think this part is definitely true for me...

I have let "notice when you are confused" and "understand the impact of your work" and "make sure you are building the right thing" and "make sure you know stakeholder needs" get kinda etched into my identity. I keep wanting to _understand_ the systems I work with and I keep getting distracted by noticing problems with its UX or implications to business process.

I can turn that voice off with deliberate effort, but I don't know how to get it to stay off.

Does anyone else have any methods for more permanently-silencing UX-worries and just cranking out code?

Why is documentation standard so low?

Even in companies where good documentation would raise revenue in a way that the sales team notices[1], someone still needs to write it and someone still needs to make the business case for writing it.

Engineers could, but many don't. If you're passionate about good documentation, but don't think you can deliver, it would be foolish to unless someone else is doing the writing.

I'm a bit of an extreme case, but Many engineers feel so incredibly uncomfortable with writing prose that they avoid it. Why? The standard of writing education for STEM-minded people is low. Why? Writing education in high school is focused on literary analysis essays rather than on learning to describe facts and systems with vibrant clarity.

[1] https://getputpost.co/overhauling-api-docs-with-gocardless-9... ---

Anecdote: At age 14, my school had poster which listed the professions one could use mathematics in. Someone pitched us on how much need there was for people who could program. Shop classes and science classes had assignments which were miniature versions of problems we could see in the real world. Nobody did this for literary analysis. I didn't know how to ask "why are we doing this?" other than as a snotty teenager saying "Hey english teacher! Justify why your life's work has meaning." In reality, I wanted to say "I'm having trouble getting oriented around this subject. I'm having trouble understanding what it means to make progress or make something good. Can you help me?"

I searched for writing advice devoured works like Politics and the English Language and Strunk and White. But they just helped me get better at editing, not at putting thoughts onto a blank page.

Anecdote: At age 17, I told my English Literature teacher that I wanted to write really good physics tutorials. She looked confused at me and said "Why? Thats so boring." At age 17, I didn't have the self-confidence to persist to find a different teacher who would be interested in that.

Anecdote: At age 20, in an engineering university, I knew that I struggled with getting the first draft of an essay done. I went to the writing center at my school. But I never built a good workflow with them for how to get the first-draft-writing process. I didn't know how to learn to write without an anxiety so strong that I felt compelled to dig my nails into my skin. I didn't know how to ask professors or TAs for help. I accepted that writing was just staring at the paper until my eyes bled. I wasn't going to learn to write. I endured my required writing classes. hoped that once I graduated, I might be able to work in a way to

Anecdote: At age 29, I had to quit a visa-sponsoring software engineering job and very quickly find a new one, because of my failures with writing first drafts interacted with a business process for immigration-law compliance.

---

I've now found two coaches and plan to spend this Saturday working on a first draft of a blog post and trying some of their strategies. Wish me luck.

Alongside a donation link, you should put a "purchase a license" or "purchase a subscription" link. That way, an engineer can upload the resulting receipt to expensify and get reimbursed by their employer.

Employers are used to paying for software licenses out of engineering budgets; Donations would generally come out of a different budget managed by someone an engineer doesn't work with day-to-day.

An important aspect of being a professional software engineer is having the backbone to sometimes say things like:

- “I don’t know yet enough about the problem to give you even a rough estimate. If you’d like, I can take a day to dig into it and then report back.”

- “This first part should take 2-3 days. 5 on the outside. But the second part relies heavily on an API whose documentation and error messages are in Chinese and Google Translate isn’t good enough. I’d need to insist on professional translation in order to even estimate the second part.”

- “The problem is tracking down a bug rather than building something, so I don’t have a good way of estimating this. However, I can timebox my investigation and if I’ve not found the cause at the end of the timebox, can work on a plan to work around the bug.”

You need to be willing to endure the discomfort of looking someone in the face, saying “I don’t know”, and then standing your ground when they pruessure you to lie to them. They probably don’t want you to lie, but there is a small chance that they pruessure you to. If you don’t resist this pruessure, you can end up continually giving estimates that are 10x off-target, blowing past them as you lose credibility, and your running your brain ragged with sleep-deprivation against a problem you haven’t given it the time to break down and understand.

But when you advocate clearly for your needs as a professional, people are generally reasonable.

Please do not downvote this comment. mikro2nd is expressing something that I've also felt and I have heard from multiple other engineers in the hallway track at conferences and in 1-on-1s. As such, even if you disagree with the opinion, it is still an important contribution to the discussion.

If you believe that there is a reliable method for producing time-measured estimates which a software engineer can learn -- a method which is not magic but is merely work -- it would be highly valuable for you to lay that out here.

The reason it is a nonconstructive attitude is that saying "4 hours" or "2 weeks" is not a direct and honest expression of what you'd mean by saying it. The honest and communicative thing to say is something like:

""" I do not know how to develop a meaningfully accurate number of days or hours that this will take. The software industry as a whole has not developed reliable best practices for estimating software tasks or for teaching those practices to other software engineers. As such, it would be deceptive and unprofessional for me to give you a number. """

To really communicate this effectively, you have to say it with confidence: standing up straight, shoulders back, making eye contact. It is uncomfortable and the sort of thing that makes me feel a bit nauseous to say, but as a professional, it is important to be honest even in the face of discomfort. To this opener, I would personally add to this statement either

"However, if you are looking to get a rough assessment of the size or complexity involved, this is the sort of task that I can take 2 hours and produce a breakdown of the components of this."

or

"I sense that what you'd really like is a judgement of how large or complex this task is. However, at this stage, the task is not well-scoped enough for me to do that. I would need to invest effort into fleshing that out. If you'd like I can timebox one (or two) days to investigate and report back with what I discover are the major components to this and whether there are likely to be more unknown components."

or

"In particular, this is the sort of task where the work to discover the problem and the correct approach to solve it is 90% of the battle. There unfortunately isn't a way to break that down ahead of time."

Depending on whether it seemed like a task similar to one that I'd done before or not--or whether it was a bug-hunt.

given a well-articulated objective (not solution)

And a clear idea of why the objective is important, or the access to inquire about that. Without the ability to know why a business goal needs to be accomplished, its too easy to start sliding back into asking for solutions rather than objectives.