[HN Gopher] Things To Do Before And After You Write Code
___________________________________________________________________
Things To Do Before And After You Write Code
Author : Ozzie_osman
Score : 66 points
Date : 2021-09-19 15:25 UTC (7 hours ago)
(HTM) web link (somehowmanage.com)
(TXT) w3m dump (somehowmanage.com)
| KineticLensman wrote:
| UK defence has the concept of 'lines of development'. When
| creating a new capability, you need to think through
|
| * the training needed to use it
|
| * the equipment it will require
|
| * the personnel needed to operate it
|
| * the policy associated with its use
|
| * the information it will require
|
| * where it will sit in an organisation
|
| * the infrastructure required
|
| * how it will be supported through-life
|
| And some others. These are a great checklist of things that if
| not considered can cause a system to fail / be unused.
|
| Also... Before enlightenment, fetch water, chop wood. After
| enlightenment, fetch water, chop wood.
| mirekrusin wrote:
| Missing from "after" is something that contributed to my career
| success - when you encounter problem, and you will, many, when
| you (small bugs etc) or your team (larger issues) solves it -
| stop and play it from the beginning in your head. Go through
| every step that you remember that you or collegues went. Pay
| attention to what you should have done instead, what you should
| have tried, now that you know where the problem was. What were
| the obvious things to check. What was waste of time. What kind of
| binary search you should have done. This alone can boost your
| performance above average quickly. And the weird part is that
| almost nobody does it; just do it and you'll see.
| henrik_w wrote:
| Great advice! It is similar to something I have been doing for
| close to 20 years now: whenever I come across a really tricky
| bug of some kind (usually one that got all the way into
| production without being caught), I write down some notes on
| it. What the problem was, what we did to find it, and what we
| did to fix it. Most inportant is the "Lessons" part (a few
| sentences) - what should be done to avoid these kinds of
| problems in the future.
|
| I've written about what this looks like:
|
| https://henrikwarne.com/2016/04/28/learning-from-your-bugs/
|
| and I have also written about general lessons extracted from
| all these notes:
|
| https://henrikwarne.com/2016/06/16/18-lessons-from-13-years-...
| quercusa wrote:
| The per-bug write-ups seem really useful. Have you used them
| for internal training or just for your own reference?
| milkytron wrote:
| I've done the same thing, but for more than just bugs.
| Pretty much any time I learn something while working that I
| think might be easy to overlook in the future, I write it
| down.
|
| Some of my findings end up in internal training if it's
| something the team needs to know. If it's something for me,
| I'll just keep it in my own notes for the next time I
| encounter it until it's burned into my memory.
| candiddevmike wrote:
| Focus on the problem at hand and don't chase technical debt
| unless it impedes you. If not, open an issue, leave a TODO, etc.
| Nothing bothers me more than finding a bunch of changes in a pull
| request completely unrelated to the scope of the issue, and
| they're most often a time sink for the developer chasing them.
| schwartzworld wrote:
| Some jobs don't allow for time to really address tech debt.
| Lots of us get in the habit of sneaking improvements in as we
| go because otherwise they never get done.
| mrloba wrote:
| Good code is produced when people can easily improve it. In my
| experience, people leave too much crap untouched because of
| unnecessary barriers, and having to create a new issue is
| definitely one of them.
|
| I'd rather review 10 extra files every PR if it means the code
| is improving. If you keep doing this, eventually there won't be
| so many extra changes because they're fixed already.
|
| I'm curious, why do you think fixing tech debt is a time sink?
| candiddevmike wrote:
| I see issues like contracts--they have a scope and you are
| agreeing to work on that scope. If you go beyond the scope,
| you're breaking the contract. Someone might already be fixing
| the tech debt via a different issue, you may need to submit a
| new RFC, etc. Management and PMs will also start to notice
| and not appreciate the risk that your fixes might cause to
| the release.
| bennyp101 wrote:
| "Understand why you're building it. If you're building it, there
| should be value to your users and the business. What is that
| value? Do you agree with it?"
|
| Is that really your concern? If you are following the spec, it
| should be irrelevant - sometimes as an engineer you are not privy
| to how things will integrate until later, unless you have a real
| concern, the "value add" is irrelevant.
|
| I dislike these "non article articles" for exactly this reason,
| it just is not reflected in reality
|
| Edit: The whole article just annoyed me, I don't know why, so
| maybe I'm just snapping at things
| plorkyeran wrote:
| I particularly don't believe that it is possible to have a spec
| which does a good enough job of explaining what is needed that
| the implementor doesn't need to know why. I've certainly never
| encountered such a thing, and all of the best specs I've worked
| with explain the why as well. It's like claiming that your code
| doesn't need any comments saying why things are done because
| you can see what is happening.
| jason-phillips wrote:
| The how and the why are what separates the garden variety
| codemonkey from the staff/principal levels.
| bennyp101 wrote:
| Yep,if you can do the how, then you'll learn the why
| Zababa wrote:
| > Is that really your concern? If you are following the spec,
| it should be irrelevant - sometimes as an engineer you are not
| privy to how things will integrate until later, unless you have
| a real concern, the "value add" is irrelevant.
|
| I have the opposite view, I think it matters a lot. As an
| engineer, I understand things better when I can see the "why".
| Being aware of the "why" means that I will follow more easily
| the spirit of the spec instead of just the word. It means I
| will be more aligned with the users, the business. All of these
| avoid the classic trap of having a dev team disconnected from
| the business, which usually leads to a bad atmosphere,
| late/failed projets.
| kwhitefoot wrote:
| > follow more easily the spirit of the spec instead of just
| the word.
|
| It also allows you to use your experience and expertise to
| tell the writer of the spec that they have written a pile of
| junk and that what they are asking for is not what they need.
| Sometimes when I have done that I have also discovered that
| it was not what they wanted either but simply what they
| thought was practicable. Together we were able to thrash out
| a better spec that achieved the ends that were necessary.
|
| I wish that people would remember that the vast majority of
| people writing code are doing it inside the same company or
| even department that will be using the final program. It is
| often the case that at least some of the software developers
| in such teams have as much or more expertise in the domain as
| the customers commissioning the software; it would be a
| dereliction of duty to fail to question a specification that
| seemed pointless, inconsistent, or inadequate to the problem
| it was purported to solve.
| Zababa wrote:
| I agree. I noticed the same as you, when I talk to people;
| sometimes they don't know what's easy, what's hard or even
| what's possible to do with code. Talking to them and trying
| to understand what they're trying to do often leads to a
| better result.
| Chris_Newton wrote:
| _Is that really your concern?_
|
| That surely depends upon both the individual's role and the
| culture in the organisation, but I tend to agree with the
| original author. As a developer, I can often provide better
| results if I'm aware of the context and not operating in
| isolation. As a manager, I get better results from the people
| working for me if we're communicating openly and often enough
| to address any questions or problems quickly, and this applies
| to software developers as much as any other field.
|
| Of course this matters more as you get more senior as a
| developer or perhaps start to take on hybrid roles like tech
| lead or software architect. However, in my experience the
| principle works very widely, except maybe for juniors who have
| enough to learn already and new starters who are still finding
| their way around.
|
| No doubt there are some projects where for legitimate security
| reasons there is a culture of need-to-know and
| compartmentalisation of information, but I suspect that across
| the industry as a whole, variations of wilful ignorance among
| developers do far more harm than good. It happens at large
| scale, like pigeonholing developers into narrow roles and
| trying to make everything possible into someone else's problem.
| It happens at smaller scales, like being too dogmatic about
| pretending we have no idea what we're going to be working on a
| few days or even a few hours later and stubbornly refusing to
| make any allowance for it in code we're currently writing.
|
| That kind of culture can become toxic and unproductive, but it
| can often be fixed by sharing information more freely with
| those who might find it useful and then having those people
| take the extra context into account when making their own plans
| and decisions. A lot of the points in the article here could be
| specific examples of that general idea, and IMHO those are all
| sensible advice.
| bennyp101 wrote:
| Possibly not, but the article annoyed me.
|
| I think I agree with a lot of your post, but I do still
| disagree that everybody needs to be aware of the end goal.
| Jtsummers wrote:
| A lack of awareness of the purpose of work can often cause
| the work to be done in a way which harms the actual
| objective. This is because the internal group doing the
| work (without any insight into why or to what end) will
| have its own objectives and incentives that are distinct
| from or in conflict with the overall objective. In order
| for an internal group like this to function blindly, their
| incentive structure needs to be properly established by
| some other group with proper insight. So even if the people
| doing the work are blind to the purpose, the ones
| establishing their measures and controls cannot be blind.
|
| This can work, and often seems to work well enough, but it
| also can fail spectacularly. See the recent Ask HN
| discussion on Google's 50 billion messaging clients.
| marcosdumay wrote:
| Hum... Are you talking from the point of view of a developer
| working in a feature fabric?
|
| If so, ok, your work will become much better if you ask those
| questions, but the party paying you does not care about it at
| all. You are just expected to deliver this feature.
|
| But if you have any amount of goal alignment with the people
| that will get the software (as little as wanting them to
| perceive your work is useful), you will get much better results
| by having a picture of what your software is supposed to do. If
| you do not have access to this information, it's relevant to be
| aware that you are not receiving all the tools you need to
| succeed.
| bennyp101 wrote:
| Sorry, I don't know what feature fabric means?
| Jtsummers wrote:
| Probably "feature factory". A group that exists just to
| churn out what they're told to do, versus a group that
| works with their customers to build what the customers
| actually want/need.
| schwartzworld wrote:
| I can't count the number of times I've done these exact steps:
|
| - see a feature request that sounds weird.
|
| - ask what problem they are trying to solve
|
| - come up with a less weird / more useful solution.
|
| As engineers we have information and skills that designers and
| pms often lack. You can just build what you're asked to build
| and you'll be fine, but understanding the value that's added
| will make sure you build it better.
| codingdave wrote:
| As a former developer, who now mostly writes those specs...
| Yes. Yes, I want my team to understand why. They do better when
| they understand. They have insights into what choices to make
| when writing the code. We have better conversations about the
| product and the work to enhance it. And they correct my errors.
| I'm not perfect just because I write specs, and I appreciate
| most of the suggestions and corrections that the devs bring to
| me.
| [deleted]
| asdfge4drg wrote:
| Understanding why you're doing something at the strategic
| level, helps you make decisions at the tactical level without
| having to go back up the chain every time. Without this
| knowledge, someone else has to make decisions that you are best
| placed to make.
| pachico wrote:
| There are some huge missing "before" items: document what you're
| about to do (possibly also in plantUML so it can easily evolve
| together with the code), ask for efficient pair reviews (about
| your strategy, your implementation, your observability plan,
| etc)...
| reqres wrote:
| I'd say there's one extra preliminary step missing:
|
| Before (0): Understand if it needs to be built at all
| drdeadringer wrote:
| Also: "Has this been invented before?" // "How shall mine be
| better than the dozen already created?".
| chrisjarvis wrote:
| but how will I make principal if we dont build our own in-
| house NoSQL database? :)
| nzmsv wrote:
| Many shops are optimized to make the kind of thinking and
| organization described in the article impossible. They keep
| throwing developers into fire after fire, leaving no time for any
| reflection and growth. I was surprised to see several
| representatives of this camp pop up on in the comments here.
|
| If as an engineer these people give you the creeps, remember, you
| don't have to work for them. If you do currently work for someone
| like that, you can get out and keep your sanity. The best places
| to work are not sweatshops.
| davedx wrote:
| It seems to me that the "ship it" and "move fast and break
| things" eng culture of the previous decade or so is slowly giving
| way to a new culture of "be careful, thoughtful and get it right
| first time". Code reviews, once relatively relaxed and informal,
| now take weeks.
|
| I don't mind the premise of "think things through before coding",
| but I'm a pragmatist and I learn most from doing, and this
| current mentality is starting to feel stifling.
|
| Whatever happened to "less talk, more action"?
| jacoblambda wrote:
| At least from my view this is a shift towards actual
| engineering culture. You'd never see a civil engineer or most
| any other engineer operate under the "move fast and break
| things" philosophy.
|
| Making prototypes and experimenting is one thing but something
| I consistently see with the "move fast and break things"
| philosophy is that production is your prototype. Sure things
| may go through testing first but at the end of the day features
| get pushed out to prod once they have an MVP and are iterated
| on and beta tested more or less live.
|
| I'd love to see SWEs be more willing to sit down, make a
| prototype, and toss the entire thing away taking the lessons
| learned to build the real thing rather than trying to build the
| actual product off the bat or trying to send the prototype
| straight to production.
|
| All this extra review and rigour is a good thing for anything
| going to production. The real problem is that we don't build
| our prototypes outside of production any more. Build your
| prototype on your own fast and loose but anything that actually
| gets near the master branch should be inspected and picked
| apart to the highest of standards.
| im3w1l wrote:
| We were in a gold rush. No point building a boom town to
| last. With the gold rush coming to an end people want quality
| again. Actually it makes me wonder if startups will stop
| being a thing too.
| Msw242 wrote:
| Yeah I hate this. Speed of delivery is way more important than
| having a developer spend 80% of their time doing QA.
|
| I don't want to pay developers to find a tester, watch them use
| the new feature using full story/posthog, etc etc. That 1)
| delays the feature because it still needs to get formal QA
| treatment and customer feedback. And 2) halves the volume of
| work an engineer can actually deliver.
| jrockway wrote:
| I think that when you split a task among multiple people,
| important context gets lost, and you run the risk of making a
| bad product. Everyone can do well individually, but taken as
| a whole, the work product falls short. Having a detailed
| understanding of the problem and solution space is crucial to
| making something good, and getting that understanding is
| expensive. Individual output in a very small area isn't a
| good metric for productivity, the results of that output are
| what's important.
|
| For that reason, I think it's important for individuals to
| own things from idea to implementation to maintenance. You
| know how best to test your software. You know why you're
| getting paged for it breaking. You should handle that.
|
| I think the loss of quality when splitting up projects among
| multiple teams (or even individuals) is why startups produce
| so much more than huge corporations. (My personal view is
| that output scales logarithmically with the number of people
| involved -- to do a project that's 4x more complicated than
| what one person could do alone, you'll need 2^4 = 16 people.
| Part of that is all the communication required to hand ideas
| over from product to engineering, hand software from
| engineering over to QA, hand maintenance over to SREs, etc.
| You can skip all that and do more with less.)
___________________________________________________________________
(page generated 2021-09-19 23:01 UTC)