Comment by 100011_100001 | Hacker News Reader

Comment by 100011_100001 | Hacker News Reader

Parent Full thread

I can go really deep talking about this, so I will just write my personal system pointers that I keep by my desk.

Iterate fast > perfect

Write it down to relieve cognitive load.

Uni-task (focus on one thing at a time)

Prioritize and execute.

Solve problems by:

a. Invert - improve by subtraction

b. Decision trees - compare outcomes, reduce load

There are two types of decisions. Hard choice (A vs B), or multiple factors (A vs B vs C, but you can do A+B etc).

Hard choice model. Is it a hard or easy choice? Does it have low or high impact. Hard to compare, low impact = apple vs oranges, focus on optimization.

Hard to compare, high impact = get impact and mitigate negatives.

Easy comparison, low impact = Go with your gut

Easy comparison, high impact = Be confident

For multi factor decisions use a decision matrix.

Understand systems by looking at the connection circle or iceberg model.

Connection circle is when you take the key elements and put them on a circle as points. If there is a cause and effect relationship you draw an arrow from one element to another. If arrows end up connecting three or more elements together you have located a closed feedback loop.

Iceberg model, top of the iceberg (what's visible) is the event that just happened, underneath that there are patterns/trends, under that structures and connections. The deepest part of the iceberg are the mental models and assumptions made by people. If it's a system I don't understand I will confirm my path down the iceberg by looking at the code, testing the code and talking to SMEs

In terms of actual code reminders I try to make it work, make it right, make it fast.

I also try to do always, then inhibit, then ignore cases that don't apply.

Minimize if statements to have consistent execution.

If a function is called from one place I will inline it. From multiple places I will try to see if I can have it happen in one place so I can inline it (plus it's an optimization thing). For complex calculations if I can't have it happen once I will try to cache it, but cache invalidation can get tricky, so I always opt for do it once.

Finally I try to write pure functions, look at parameters and return one or more computed value.

n terms of actual code reminders I try to make it work, make it right, make it fast.
I also try to do always, then inhibit, then ignore cases that don't apply.
Minimize if statements to have consistent execution.
If a function is called from one place I will inline it. From multiple places I will try to see if I can have it happen in one place so I can inline it (plus it's an optimization thing). For complex calculations if I can't have it happen once I will try to cache it, but cache invalidation can get tricky, so I always opt for do it once.

Finally I try to write pure functions, look at parameters and return one or more computed value.

What programming languages are we talking about here?

I primarily work with Java and Python.

I mentioned in a top comment that is probably lost in the comments that I vouch for "if you're the smartest person in the room, find another room".

If you've got an suitably anonymous email address I can contact you on, I might be able to offer that other room. (Or you might think it's shite, which is fair).

But yeah, my current employer was my other room. Got to experience imposter syndrome again for the first time in a long while.

>Java and Python

Just lost your credibility lol.

Python is alright but... seriously? Java?

Can you talk more about your method for solving problems? That's normally where I get stuck.

People get stuck solving problems for various reasons. For me, I think more clearly when I write. The primary benefit is that it stops having to mentally re-establish my logical premises to make sure my conclusions are sound.

Anyway, the hardest part of writing code is starting. Why is that? A lot of times it's overwhelm, you see the task, it appears large and you don't know what to start.

My solution is simple, I start writing the steps I need to take. This will be easier with an example. To not get stuck in weird debates let's pretend the ask is that I need to build a house extension for someone.

I will start breaking that down, in bullet points.

* Figure out location of the extension

* Find out dimensions of the extension

* Order wood and nails

* Bring hammer on Monday to start

At this point I might know what kind of wood I need, hell I might even need to buy bricks. But I have a semblance of steps. I can talk to the client and ask specific questions.

As I go through my list I expand it or make it more focused as I go. Out of habit I also tend to mix thoughts and realizations in my bullet points.

Then as I am going through the solution the following days I can see my thoughts expanding and increasing in specificity.

There is another thing this does. If I find it hard to come up with a few bullet points it means the problem is too vague or I don't understand it well enough. Instinctually you will know if it's lack of knowledge or vague problems. If I lack knowledge I read about it or talk to an SME. Vague problems can be solved by talk to the Product Owner, Business Analyst or a client if it makes sense.

Once I grasp the problem, get basic questions answered I go through my bullet list and refine it. That's when I try to design things. After I have a design I try to see if I'm making any assumptions. Personally I prefer to test any assumptions I have.

I rather find out my assumption is false at the design phase than later. Granted sometimes things can get still trip me up, or give me a false positive.

I don't spend a ton of time designing. If I can I will pitch my design to someone I consider smarter than me to see if they find holes. I prefer people that think more breadth first, because I think depth first. Their strengths is my weakness.

Most of the time in the act of my pitch I will find assumptions I have made or I will realize that what I am saying is overly complex so it probably means I didn't design it well. So I iterate.

Designing doesn't take me long most of the time. I have learned that I think better when I code than when I design.

When I start coding I use a dirty version of TDD. Instead of write test, write code to pass test I follow a different pattern

I write small parts of code that satisfy the most likely case and I write the first step of the most likely case.

For example if I was writing a rock paper scissors game, the first part would be to to right the main method framework and print "welcome to rock paper scissors game". Then I run the code to see it's good.

Next step would be to accept input. Test that. Then write the logic for determining what the CPU will throw. Test that. Then how to determine the winner. Test that. Then create the "you win/lose" message. Test that.

Once that's working I'll start to worry about things such as, what happens is they press enter without any input. What if they miss type a word. I might decide that I would be easier to make it multiple choice, where a = rock.

This is a simplified and contrived example. Sometimes I'll write things I consider easy in one go, but if I have doubts or I am starting to touch complex objects or logic I start testing more frequently.

When I test I don't sit, I keep writing code while the test is running. I test excessively but it helps me to see unintended consequences quickly since my code to test cycle is short it's really easy to identify the source of my woes.

Reply on news.ycombinator.com