[HN Gopher] Dealing with the Perfectionism Trap as a Developer
___________________________________________________________________
Dealing with the Perfectionism Trap as a Developer
Author : jebraat
Score : 23 points
Date : 2022-08-31 20:42 UTC (2 hours ago)
(HTM) web link (jebraat.com)
(TXT) w3m dump (jebraat.com)
| michaelwww wrote:
| _" Make it work, then make it beautiful, then if you really,
| really have to, make it fast. 90 percent of the time, if you make
| it beautiful, it will already be fast. So really, just make it
| beautiful!"_ - Joe Armstrong
|
| As hard as it is to resist, I would argue that if you other
| modules to make work, move on and leave making the current module
| beautiful for later.
|
| That said it's really hard to leave working but ugly code alone
|
| I find a lot of freedom in coding for myself. In other words code
| that no one else is ever going to see. This goes a long way to
| silencing my inner critic. If I ever want to open source it, I
| can make it perfect at that time. This is why I don't keep my
| code on github. When I write code for myself I can express myself
| the way I want to, which is not necessarily the "standard way"
| that someone later might a "code smell"
| jebraat wrote:
| Thanks for the comment Michael!
|
| I 100% understand the "it's really hard to leave working but
| ugly code alone" sentiment", as I get the same feeling a lot of
| the time. That is one of the reasons I wrote this article.
|
| I often have to fight myself to move on to do work on other
| things.
| michaelwww wrote:
| Other programmers can be harsh critics and it's important not
| to internalize these critics. This isn't a knock on other
| programmers, but the criticism is often based on their own
| perfectionism!
| slindsey wrote:
| Those "other programmers" that are "harsh critics" are
| often ourselves. How many times have you (any programmer)
| looked at your own old code and thought, "what they hell
| was I thinking?"
|
| I can't count the times I've looked at ugly code, fired off
| `git blame`, and found out it was me.
| MrLeap wrote:
| Code that serves as a highway I try to make as clean as
| possible. Code that serves as a cul-de-sac just has to work.
| Aqueous wrote:
| Perfectionism is a pitfall, but agile development has led a lot
| of developers to prize velocity over correctness. Many seem
| believe that any upfront mistake can be fixed through iteration.
| The truth is that there are things that you _can 't fix through
| iteration._ Things like having an incorrect data model. Some
| things need to be perfect up front or you will quickly find
| yourself boxed in down the road as you try to extend the system.
|
| Once you've gotten the right design at the center of your system,
| understanding not only the current requirements but also likely
| future requirements as well, scrum away. It's just not OK to blow
| the "big picture" decisions that you need to do in order to build
| a piece of software the right way because you want to move fast.
| solarmist wrote:
| > The truth is that there are things that you can't fix through
| iteration. Things like having an incorrect data model.
|
| Yes! I spent a year iterating on my prototype for my startup
| for precisely this reason. The data model kept changing and
| that had repercussions through every other part of the
| prototype. Often leading to reworking entire components.
|
| The data model is that the core of everything for my prototype,
| so it was more than worth the time spent.
| CodeWriter23 wrote:
| The author is not wrong. But when you scale up is when you pay
| the price for expediting processes earlier.
| layer8 wrote:
| > Treat digital products like ever-changing drafts
|
| Sorry, but no. As a user, this is the bane of "modern" software.
| jebraat wrote:
| I get where you are coming from. I don't think anybody wants to
| use bug riddled software. I also think some companies take it
| too far with releasing software to the general public (not
| alpha/beta) that isn't refined enough. I suppose corporate
| pressure to release things on arbitrary deadlines also doesn't
| help.
|
| IMO the beautiful thing about software is, that we can push
| updates and improvements pretty much instantaneously. Whether
| that is adding features to a working product, or fixing bugs
| that slipped through during development.
| rileymat2 wrote:
| As long as they are honest about the current state of it.
| Often, I rather have something that I can struggle along with
| than nothing at all.
| layer8 wrote:
| It's not primarily about bugs, it's about everything
| constantly changing, from UI, look&feel to how features work.
| This is a constant cognitive load to users, a perpetual need
| for them to readjust to the changing software. As a result,
| the software never feels finished, doesn't feel solid, and
| often appears not to be well thought-out. This gets in the
| way of the "it just works" the user wants, in a major way.
|
| The argument is not against enhancing and improving the
| software, it's against delivering a "draft" (as you say) to
| end users, it's against constantly changing the design and
| working of features. Delivering a "draft" (or prototype) is
| only acceptable for beta users, or in an initial design phase
| involving the future users in the design process. It is not
| acceptable for released software intended for productive use.
|
| Users want stability. They want the software to get out of
| their way as much as possible, to be reliable and
| unsurprising, to remain working in the familiar way.
| jebraat wrote:
| What if the requirements change?
| layer8 wrote:
| That has barely anything to do with treating delivered
| software as unfinished drafts.
|
| If requirements change, then this has to be carefully
| coordinated with the affected users, in particular if
| they aren't the ones defining the requirements, or if the
| user base is not uniform and the requirements may only
| change for a portion of them. In any case, requirement
| changes affecting how users operate existing
| functionality shouldn't be a frequent occurrence.
| dividuum wrote:
| > IMO the beautiful thing about software is, that we can push
| updates and improvements pretty much instantaneously.
|
| It is, but that directly results in garbage software being
| released, because ,,we can fix problems later". And it also
| means you can now perfectly balance perfecting your software
| with providing the resulting support for your pile of
| garbage. Which I guess is the reason I have to call support
| every third time im I'm trying to use an EV charging station
| because their software shit the bed again. </rant>
| rglover wrote:
| One of the biggest contributors, arguably, to the mediocrity of
| modern software is the rejection of the inner voice that says
| "you can (and should) do better" as "perfectionism." No offense
| to the author, but imo this is a platitude that has done far more
| damage than it has good.
|
| A few quotes to contextualize the thought (ones that I reference
| when I try to weasel out of doing something properly):
|
| _"An important part of making good things--it's extremely
| underrated in current day society--is having a critical eye for
| the things that you're making and assessing 'are these things of
| an appropriate quality, do these live up to the standard of what
| I'm trying to create?' That's why it's not fun sometimes. But
| it's also what enables it to be a peak experience in the end when
| you succeed."_
|
| - Jonathan Blow
|
| ---
|
| _"Doing something quickly is not the same as doing it well."_
|
| - John Hegarty
|
| ---
|
| _"Any suppression is regression."_
|
| - Kapil Gupta
|
| ---
|
| _"If you walk the path of mastery, you're going to have to walk
| it all alone. There is no one who is going to accompany you
| because no one has been taught that. No one believes that. That's
| not in the water and in the food and in the air. You're basically
| going to have to breathe a different sort of oxygen."_
|
| - Kapil Gupta
| eternityforest wrote:
| One can perfect the software without perfecting the code.
|
| A bad overall architecture is unmaintainable.
|
| An ugly 30 line pure function that has unit tests and hasn't
| needed changes in 5 years is just meh. 50 of those ugly pure
| functions are still not going to break a project. They could be
| untangled at any time as needed.
|
| 50 decent but not great functions are definitely not going to
| break a project.
|
| So much perfectionism is at the level of functions and variable
| names. Some makes things worse, when people reinvent nontrivial
| functionality instead of using widely trusted libraries, like
| as if work projects are their personal playground of weekend
| educational stuff.
| allenu wrote:
| To me, it's really context-dependent and when working on a
| solution, you may need to take into account the business
| objectives and make the right trade-off in terms of time spent
| and "quality" of the design.
|
| Architecture-level designs are important to get right as they can
| constrain your future self's ability to scale or adjust how the
| product works. However, it's also possible to spend way too long
| making a very open-ended architecture whose features you never
| actually use. (It may turn out you "build it to throw away" if
| you learn even more about the space you're working in as you go
| along.)
|
| If you're working on a product and don't even know if it's
| something customers would use or want, I would say erring on
| velocity is more important than necessarily getting everything
| "right" in the design or even making the code beautiful. The
| thing that will most likely "go wrong" for you is that you built
| a product nobody wanted and not that the code just wasn't perfect
| enough. Better to get it in front of people sooner so you know if
| it's worth pursuing. Obviously, making that nuanced trade-off
| between "high quality" and "good enough" depends on your skill
| level and being able to recognize where things could blow up in
| your implementation if you do get it wrong.
|
| Writing code is not done in a vacuum. We don't get to just write
| the most beautiful, optimal things with endless amounts of time.
| There are real business constraints and objectives we need to
| meet, and the trade-offs we make in terms of time spent should
| take the context into account. Unfortunately, most of are so
| separated from the real business objectives of the company
| leaders at the top, making it difficult to make the appropriate
| trade-offs (or even caring one way or the other). It often simply
| turns into "My boss wants this done in 2 weeks, but I would like
| to do it right and that will take at least a month."
| TrianguloY wrote:
| Coding whatever first ugly solution you come across is horrible;
| taking days deciding whether to use pattern A or pattern B for
| something that probably will change in a few months is horrible
| too.
|
| Find the balance between thinking of a better way, and the time
| it takes to coding it.
|
| Personally I've found codebases that could be simplified
| enormously just by using a different library, which I found just
| by searching a few minutes before touching it. You and future
| developers will probably be grateful.
___________________________________________________________________
(page generated 2022-08-31 23:00 UTC)