Hacker News Reader

Comment by hazz99 | Hacker News Reader

Semi-related.

Whenever I'm building something, I get really strong tunnel vision. Part of what makes me a good engineer – submerging myself extremely deep and specific context, "the zone" – seems to work against me becoming a good product person. There's always product stuff I seem to forget, or don't pay attention to, or I end up focusing on the wrong things.

After "shipping", however, the tunnel vision goes away. I can view my work with a level of clarity. Some features I built might be valuable, and some won't.

By splitting my work into build/evaluate phases, rather than continual building, I've become much better at focusing on the impact of what I'm building, and not the engineering in-and-of-itself.

I have a terrible habit of spending too much time building, and not enough time thinking/marketing/etc. This is how I try to manage that.

View on HN

This level of knowing oneself is gold. The older you get, the better you get at managing your self and your (sub-optimal, emotional, human) tendencies.

When you are young you may think that you can just adapt to anything (I did). But you often can't. You will be lazy, procrastinate, feel like you deserved a relaxing day, get cranky for (un)known reasons, etc. You will have emotions, and they are not rudimentary things you can ignore because the annoy you from time to time. They are you and they need to be listened to and understood.

This is what experience is to me: Getting to know yourself and riding your own waves of enthusiasm and productivity and knowing when to stop and reflect or seek help or when to accept your shortcomings and move on without shedding tears. To know when you are fooling yourself and know that you will get disappointed in yourself and will develop negative emotions and learn how to avoid that by being more realistic about your abilities (and time management skills).

More an more I accept deep down that I won't be the next president or the next Steve Jobs even though my parents told you I could do anything I set my mind to! And I know that that is ok.

Great insights.

> parents told you I could do anything I set my mind to! And I know that that is ok.

Well that truism only misses nuance, it's really true you can/could/will do anything you want, If you do believe in free will after all.

I would just add the stoicism on internal/external locus of control.

IMHO the part parents mostly miss, is you cannot control how others, as in other humans, society, et all, will react to you/your actions/your creations, or if you will even be noticed or not before you're out of the game...

Just look at all the bullshit some scientists, artists, businessmen, etc or anyone trying to challenge the status quo, had to go through just for the mere fact that their ideas didn't match those of their time...

As someone who studied and worked at art school let me assure you, that this is quite normal.

Some people just are better at changing their doing-hat to the editing- or evaluating-hat in a rapid fashion than others. Being (and staying) conscious about this is already 80% of the solution. However the real reality check is always when you have a room full of people look at ghe thing you made.

If it helps, try to make rituals around the reflection part. Be it something simple as putting your hands into your pockets, making a cup of tea or showing it to a friend. Everything that gets you away, everything that makes you explain it to aomeone else etc. will help.

For me, it really helps writing the documentation. I usually come back and change a feature while writing. I dislike explaining things to people, so I change it as much as possible so it becomes as easy and quick to explain. I call it DDD. Documentation Driven Development.

When possible, I practice full DocDD (DDD is taken). I write a short documentation before the code, write the code, change the documentation to reflect the code, and then change the code to improve the documentation.

You may realise this, but DDD usually refers to 'Domain Driven Development'.

> Some people just are better at changing their doing-hat to the editing- or evaluating-hat in a rapid fashion than others

I only recently realised that, for me, "dev mode" and "product mode" are entirely distinct. I'd been trying to mush them together in a haphazard way, with haphazard results.

In my opinion, this is a really important insight. It's analogous to the De Bono thinking hats, divergent/convergent thinking, etc – distinct phases of cognition that can't happen simultaneously.

> If it helps, try to make rituals around the reflection part.

Great idea! Is this something you learned in art school?

In my experience, every art student seems to incredible at "shipping". I've always been jealous. Way better than most CS or business grads. I guess it's a core part of the degree?

There's the famous study about 2 groups of pottery class, one group was asked to make one perfect vase, the other to make as many vases as possible...

Guess which one ended up with just not more vases but much better quality ones...

Focused/directed practice makes perfect, each iteration your brain is strengthening the pathways associated to that activity, making it easier for you to add more nuance/attention to detail at each iteration...

One can always keep practising without focusing in improving, which isn't as useful...

Strong agree, for me the idea of showing something to a colleague immediately makes me able to view it from a different lens. Regular design critiques are really valuable, even if the person you are showing it too isn't an expert, because it gets you into a different mode of thinking, you can't do mental shortcuts when you are actually explaining things so it forces you to be concrete.

They idea of turning it into a ritual is awesome. I’m definitely going to try that because it’s something I’ve struggled with in the past. I find building things into habits is the only way to maintain them in the long term.

I have realized something similar recently.

When building a website I would use bootstrap or similar to design the website as I implemented it.

Recently I have been designing the website in figma some days, and implementing said design other days, and my productivity had skyrocketed.

For me, it simulates a boss giving me requirements. I can focus on the task at hand without context switching all the time (or that is my rationalisation)

Edit: typos

Yes! I discovered the same thing, but with Sketch. I think it's because you can explore the problem space, and converge on solution, much faster when you don't have to bother with code.

Going further down that line of thought, pen and paper really works. You don't have to bother with colours, fonts and rounded edges.

A fun exercise I do, when solving a creative problem, is this:

1. Divide a sheet of paper into 8 squares

2. Set a timer for 40 to 60 seconds

3. For each square, start the timer, and attempt to draw a different solution in each box

This forces you to stop worrying about the individual ideas, and focus on generating lots of them. It also gets you past the "immediate solution" thoughts you have, and into more interesting ones.

At the end, you can collate the ideas, and pick the best parts from each one.

That's a great trick, I'm going to steal it! I tend to naturally go somewhat depth-first instead of breadth-first, and the quality of my idea generation often depends on how much working memory I have, and how big is the canvas on which I put my notes (I really like my infinite virtual whiteboard on my sidearm computer).

The split also applies to developing code. I've learned to switch quickly between two modes: I either focus on typing code, or on architecture/design decisions. When I coding is getting hard - I feel lost, unsure about what to write - I switch to design mode. When I feel I have something conceptually sound and my brain doesn't want to generate more ideas, I switch back to coding. This can happen multiple times per day. The point is to be always working in the mode that's easier to make progress in at a given moment.

It's probably an obvious technique to many, but I've worked with people who struggled with making these switches - they tried to power through coding even though it turned spaghetti, or considered "design phase" to be something Big to be done seldomly and up front. But it's wrong. The mode switch isn't a big deal - preserving the context in your head is. I solve that by writing down any outstanding thoughts before mode-switching. Often as a string of //TODO //FIXME //NOTE in code.

I keep a running project journal in a google doc with to-dos and just stream-of-consious thought about the problem at hand. If I have an idea for something that's not a current priority, I put it in under an out-of-scope header. I can come back and collect it later when I'm in a big picture planning phase and it lets me stop carrying the mental weight of "I want it to be perfect" that leads to paralysis because I can't implement everything all at once. Writing down my thinking helps recover from interruptions, which are frequent with kids underfoot.

> "(I really like my infinite virtual whiteboard on my sidearm computer"

what software do you use for your infinite virtual whiteboard?

EDIT: whoops, just saw my Q was redundant; thanks for responding to the other comment

https://concepts.app/en/

What is a sidearm computer? How do you manage your infinite canvas?

It's how I call the computer I use in situations when I can't use my primary computer. E.g. on the bus, in the bed, while going for a trip. My primary computer is a powerful desktop machine, and I pick the supporting computer to be light and mobile, but preferably powerful enough to handle sophisticated tasks on its own.

(This is through analogy to a soldier, who carries a primary weapon - perhaps one that's heavy and unwieldy, like an anti-materiel sniper rifle, or one that they can't move by themselves, like in artillery teams - but is also issued with a pistol as sidearm. While having limited range and lethal power, a sidearm can also be grabbed, aimed and discharged quickly, and can be carried and used in situations where the primary weapon cannot.)

My current sidearm is a Dell 5290 2-in-1, with a stylus. Basically a cheaper version of Microsoft Surface. I use a vector drawing app called Concepts[0], which offers an infinite canvas, and is streamlined for use on tablets with pens. This is as close to a good whiteboard experience as you can get on a computer - you draw as if on paper, and then freely pan/rotate/zoom the canvas (or your drawings).

I don't really manage my canvas, I just keep the app open, make drawings and notes and diagrams, and occasionally sort them into "galleries" when the main screen gets too crowded.

[0] - https://concepts.app/en/, has versions for Windows UWP, Android and iOS.

I've used that method, too, with great success! Are you familiar with design sprints[0]? I think I learned it from there. FWIW, design sprints are a really good method to find a solution to a given issue in a decent amount time[1] (not too slowly but not too fast, either, as to not overlook alternative, superior solutions).

[0]: https://designsprint.org/

[1]: Those 4 days they mention on the website can often be reduced to a day or two once you've already done the sprint in the same problem area a few times (and provided you're tackling a small enough and specific enough issue with your sprint).

Reading these comments has me asking "Does nobody use whiteboards anymore? Do they just start coding?"

Serious question: why use a tool like Figma that can capture so much detail? Don't you feel like it's implementing it twice? As compared to a napkin sketch that lets you see the detail you care about, but without less fussing to get just the right widget everywhere.

Or do you just not go the full distance a design-only designer might, and do more of a just-the-critical-stuff approach in Figma as if it were a sketch?

I used photoshop for this level, kinda specifically because it's not intended for this and I can't take it too seriously. I fiddle with and position the art, add some text boxes, etc, and squint a bit to see how it looks in broad strokes.

I've been struggling with something similar, although I think that in my case it's tunnel vision and the impostor syndrome.

I often get completely lost in the minute details, and find it really, I mean, really hard to move on to more important things in the bigger picture.

Then, just getting stuff out and sharing it with people becomes a chore as soon as I'm done with the more difficult parts of work.

Things I've tried:

- follow TDD and XP, Design Thinking/HCD (iterative methodologies that allow you to slice problems differently, split them into smaller chunks)

- Build smaller products/tools (most of my apps are really, really tiny, an old example: http://facade.photo)

- Build a tool to separate writing from editing (https://sonnet.io/posts/ulysses/)-I've been using it every day for the past 1.5y

- Force taking regular breaks, even if I'm focused, to regain context (pomodoro)

- therapy (I got to the point where building a calculator in JS took me a week, which made me realise that maybe there are some deeper problems at play here)

I was at the point where I would run courses on having this high-level perspective: XP, pairing, workshops on Human Centred Design, and ironically, I find all of that paralysing in my solo work. So, I guess the last point from the list (therapy, taking time off) seems to be the most helpful one. I still find all of that extremely frustrating, almost destructive.

Side note: either Clean Coder or Pragmatic Programmer criticises being "in the zone"/the state of flow precisely for the reason you've mentioned. I recommend reading both, although I think the approach to the craft they describe is to put it mildly, draconian.

Elon said it well in an interview regarding Starship development, “most common problem in engineering is optimizing something that shouldn’t have been built in the first place”, https://www.youtube.com/watch?v=cIQ36Kt7UVg

Broaden your view. You are not put on earth to write great code, but to solve real world problems. Software development is a means to an end, not the end itself.

Well, Elon and SpaceX has the luxury of having a total control of the product's technical requirement.

Most probably this is because Elon, being the CEO, has enough technical prowess to oversee both the real-world requirement and technical aspect of the product. This allows the company to streamline the practical/from-real-world requirement and the technical specification, therefore eliminating "things that shouldn't have been built in the first place".

This is luxurious because other tech company either does not have and/or does not realize it must procure.

One of my personal daydream is to be in a period where this streamlined real-world requirement and technical specification is common, not a luxury.

Excuses. What organization your work for is a choice you've made. You need to make sure you work for a well functioning one, few things are more important. If you can't get hired by one, start one yourself.

Not excuses. I'm pointing out that to achieve the streamlined real-world-tech-spec, you need that kind of person.

My wish is not only for my organization but for everybody. The world might be a better place if things are cheaper to maintain.

You don't need to be Elon Musk to think hard about if you are optimizing for solving real world problems or something else. It's a habit of mind and the courage to change your circustances if you find yourself in a situation where it's not possible do things the right way (e.g. in a dysfunctional organization).

Relevant similar quotations: https://quoteinvestigator.com/2017/02/09/efficient/

Sometimes though, the engineering exists to create art. Because we are all human and we all in our own way yearn to answer the question "What is beauty?"

Including the folks at Valve.

> Part of what makes me a good engineer – submerging myself extremely deep and specific context, "the zone" – seems to work against me becoming a good product person.

I feel a lot of this from the other side of the table. Part of what works against me in engineering is my lack of fluency in focusing deeply on very insulated challenges for a long enough period of time. I've always said this works against me but makes me great at the product side of the house because I can leverage my natural inclinations better.

One of the characteristics of Flow State is

> A loss of reflective self-consciousness

Developers who spend all their time in flow state are not thinking about other people. Worse still, in many cases their emotional attachment to the code they wrote in Flow can be very high, leading to defensiveness and rationalization.

Really any time you write a module someone will take issue with how you did it, so it can be a little difficult to discern if “you do it too”. If you can make most of your decisions outside of Flow, this seems to go a bit better in this respect.

If you get stuck, leave your desk, snap out of it. Think. Which is another way of saying that if you’re going to rely on Flow then you’d better figure out how to drop in and out of it more or less at will.

Yeah; related tangents: I think it was Dr Ben Hardy whose advice resonated best with me: "Always make decisions in your peak energy state". It means I'm sometimes overly ambitious or set the bar too high, but overall it serves me well.

Also, acknowledging and leveraging different modes of thinking: "open" or expansive, broad, associative, free-form on one hand vs "closed" or focused, directed, narrow, deep on the other. We tend to associate flowstate with the latter, but some of the most profound and impactful work I've ever produced has stemmed directly from the former.

So many thoughts here; this topic fascinates me.

I feel that. Writing code and zooming in on individual tasks is much more my jam than zooming out and seeing the whole picture.

At my current job I kinda have to do all of them, I'm the solo developer on the UI of our application (my colleagues work on the C runtime, the UI generates configuration for it and shows diagnostics and statistics data). What this project really needs though is more people working on it, and the way things stand I'd be in the lead there, so I have to take a step back from the nitty-gritty.

That was satisfying to read. I think many devs have the same issue and are not nearly as impact-driven as they should be. Let's start another cult : Impact Driven Development

I'm on the other end of that curve; I tend towards thinking and mentally mapping / exploring permutations and implications at the expense of build/ship/iterate. I've learned to adopt a bias to action when called for, but it's a conscious effort. IMHO teams with a range of cognitive styles are the most effective.

Yeah the plan -> build -> evaluate cycle is a healthy way to ship. I do that too. Monday are my plan days with lots of alignment meetings.

Friday’s are my evaluate days with tons of both customer and internal calls to get feedback.

Tue-wed are my build days. I try to not to have any meetings after lunch. That is my in-the-zone time.

Engineering and marketing have contradictory value-systems, so it's easier to have them in separate people.

I wonder if separate rooms, with distinct smells, and wearing different hats would ease the transition.

I'll elaborate: engineering's value-system is about intrinsic value; marketing's value-system is about extrinsic value.

Engineering is about the thing itself; marketing is about the market. Engineers want the thing itself to be good, by various metrics; marketing is motivated by market needs/wants and competition/alternatives.

For example, coherence and high performance are properties of a product, that an engineer might value. But for the market, a shopping list of properties at good-enough performance, may be what's needed.

OP's "tunnel vision", undistracted by the market, is how the best engineering is done. But of course, maybe nobody wants or needs this - that's the role of marketing.

Typically, engineering is market-led, with the marketing deciding what is to be built and engineering building it. But because engineers can create things that the market didn't imagine was feasible, it is sometimes engineering-led.

Henry Ford apparently said the market would have wanted "faster horses".

Startups ideally exist at this intersection, where engineeing creates things that never were, and marketing creates needs that never existed.

Note startups are often co-founded by a duo of engineering/marketing - because these inconsistent value-systems are easier to have in separate people.

Engineering at its worst and marketing at its worst have contradictory value systems.

At their best though, they are as harmonious as art and mathematics.

https://www.youtube.com/watch?v=-vZ_E1OO_PY

Depends on your lens.

Both solve problems.

When and how do you transition from thinking/marketing/etc. to building?

And how do you handle situations where:

(1) you know you must ship, but it’s not good enough?

(2) you know you must think/market/etc., but you’re building?

A lot of it comes down to being intentional. You can only fit so many features (functional and non-functional) into any given time window. So you are either selecting the features and allowing the time window to expand to accommodate it or removing features to hit the window. There can be some negotiation for sure, but those are your levers.

I think staring this fundamental truth in the face goes a long way. Very few projects can allow the development window to expand indefinitely. A startup needs customers and feedback, even if only for another funding round. An established company generally has deadlines driven directly or indirectly by customers. Both can slip a little, but not indefinitely. Not all features are strictly necessary. So you optimize for time and importance.

The hardest thing to get over is that you will never think it's good enough because it could always be better. But existence is a feature. The ultimate feature. So you'll have to ship an imperfect product and iterate. Experience usually gives better hand-holds on shipping something.

I also tend to find that half-features please no one. You're better off either finishing something or cutting it.

I'm the most dysfunctional wannabe founder ever, so I am 100% not qualified to answer this :)

With that said, I think product/solution ambiguity is rooted in confusion about the problem being solved. It comes from starting with an idea, and not a painful problem that people already experience. Alternatively, from a problem that exists, but is incredibly ill-defined.

It would be disingenuous for me to comment further, because I'm still learning! My view is it's easy to create a solution, but really hard to find & well-define a really painful problem.

My biggest problem is thinking instead of building.

I’ve had and still have some great ideas, and that’s all they amounted to thus far.

When I’ve started to build, I get stuck spending a lot of time to produce very little, because I try to implement a novel way to do something simple that no one would want while deploying it easily and handling requests quickly.

My greatest dream is that I write something eventually that actually works and that people would want to use.

My greatest fear is that either that no one would use it, because I don’t need it or understand the need for it, or that it would work, not scale, and I’d have leveraged everything and let everyone and myself down.

Also, execution bores me. It’s more fun ideating, thinking and analyzing, but I’d like to be responsible for creating things that are interesting and solve problems or make life better.

I’m unsure where the risk-averse creative fits into a startup CEO role.

Your fear assures your fate.

Accept that is the case and let yourself code anyways. Then you may end up being surprised by what you can accomplish.

Reply on news.ycombinator.com