6 ms·

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

by hazz99 6y ago

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.

atoav 6y ago
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.
- danybittel 6y ago
  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.
  - marcosdumay 6y ago
    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.
  - OJFord 6y ago
    You may realise this, but DDD usually refers to 'Domain Driven Development'.
- hazz99 6y ago
  > 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?
  - agustif 6y ago
    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...
- mattbuilds 6y ago
  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.
- polytely 6y ago
  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.
TheColorYellow 6y ago
> 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.
Toine 6y ago
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
mejutoco 6y ago
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
- hazz99 6y ago
  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.
  - TeMPOraL 6y ago
    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.
klingon78 6y ago
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?
- hazz99 6y ago
  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.
  - klingon78 6y ago
    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.
    - throwaway98797 6y ago
      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.
Cthulhu_ 6y ago
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.
rpastuszak 6y ago
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 http://facade.photo) - Build a tool to separate writing from editing (https://sonnet.io/posts/ulysses/)-I've 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.
teekert 6y ago
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.
- agustif 6y ago
  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...
hallqv 6y ago
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 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.
- valand 6y ago
  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.
  - hallqv 6y ago
    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.
    - valand 6y ago
      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.
      - hallqv 6y ago
        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).
hinkley 6y ago
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.
- chrisweekly 6y ago
  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.
chrisweekly 6y ago
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.
hyperpallium2 6y ago
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.
- throwaway98797 6y ago
  Depends on your lens. Both solve problems.
- afarrell 6y ago
  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 https://www.youtube.com/watch?v=-vZ_E1OO_PY
- hyperpallium2 6y ago
  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.
nojvek 6y ago
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.

by hazz99 6y ago

atoav 6y ago

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.

danybittel 6y ago
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.
- marcosdumay 6y ago
  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.
- OJFord 6y ago
  You may realise this, but DDD usually refers to 'Domain Driven Development'.
hazz99 6y ago
> 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?
- agustif 6y ago
  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...
mattbuilds 6y ago
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.
polytely 6y ago
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.

TheColorYellow 6y ago

> 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.

Toine 6y ago

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

mejutoco 6y ago

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

hazz99 6y ago
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.
- TeMPOraL 6y ago
  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.

klingon78 6y ago

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?

hazz99 6y ago
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.
- klingon78 6y ago
  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.
  - throwaway98797 6y ago
    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.

Cthulhu_ 6y ago

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.

rpastuszak 6y ago

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 http://facade.photo) - Build a tool to separate writing from editing (https://sonnet.io/posts/ulysses/)-I've 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.

teekert 6y ago

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.

agustif 6y ago
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...

hallqv 6y ago

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 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.

valand 6y ago
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.
- hallqv 6y ago
  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.
  - valand 6y ago
    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.
    - hallqv 6y ago
      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).

hinkley 6y ago

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.

chrisweekly 6y ago
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.

chrisweekly 6y ago

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.

hyperpallium2 6y ago

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.

throwaway98797 6y ago
Depends on your lens. Both solve problems.
afarrell 6y ago
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 https://www.youtube.com/watch?v=-vZ_E1OO_PY
hyperpallium2 6y ago
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.

nojvek 6y ago

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.