[HN Gopher] A Senior Engineer's Check-List (2019)
___________________________________________________________________
A Senior Engineer's Check-List (2019)
Author : gautamsomani
Score : 186 points
Date : 2023-09-10 17:57 UTC (5 hours ago)
(HTM) web link (littleblah.com)
(TXT) w3m dump (littleblah.com)
| crtified wrote:
| Point 1 (" _Understand the business aspect of your work, and what
| makes money. Eventually, only that matters._ ") is depressing to
| me.
| TensorTinkerer wrote:
| Really digging the list, especially the emphasis on simplicity in
| systems. Reminds me of that age-old principle: "What is the
| simplest thing that could possibly work?" I've been on teams
| where we battled convoluted systems. Sometimes a refactor, even a
| daunting one, clears so much technical debt and revitalizes the
| team.
|
| The 'ask "why"' bit? Gold. It's not just about coding but
| understanding the bigger picture. Feedback loops in software?
| Amazing. Feedback in career growth? Equally crucial.
|
| It's a solid reminder that our game isn't just code; it's the
| soft skills too. They can seriously make or break your
| trajectory. But as always, while guides are great, everyone's
| path in tech is unique. It's like code; it evolves, iterates, and
| adapts.
| [deleted]
| sacnoradhq wrote:
| > 8. Do not be adamant about your views.
|
| I worked at a MAANG where this was not the case. The pecking
| order of "seniority" was who was the most "right" and who could
| poke the most holes in everyone else's ideas while denying
| others' contributions while bragging about how essential and
| important their work was in a semi-agro manner that discouraged
| dissent and curiosity.
|
| In my view, marks of intelligence include lacking strong biases,
| comfort with ambiguity, be willing to propose hypotheses,
| experiment, gather data, and be proven wrong.
| shikshake wrote:
| "Strive for deep technical expertise in technologies used"
|
| In general, how would someone go about this? Is it just something
| that should happen over time or is there a method/goal to strive
| for?
| Agingcoder wrote:
| Read books, on a variety of topics, including the ones you
| don't know about. A book will give you a much broader and
| deeper understanding of most topics than random blog posts on
| the internet. Make sure you read one or two a year, and think
| about how you'd apply what you're learning at work. Even
| better, find an actual application at work.
|
| I've found that solving tricky problems ( horrible network
| related issue, performance bugs, strange behaviour of
| program/framework/os, someone you know deciding to use new tech
| you don't know about etc ) is usually a good way of finding a
| topic to explore.
|
| Find someone who's interested in actively learning things, it
| makes things a lot more pleasant, and it's easier to remain
| motivated. You don't have to learn the same things - just share
| the fun stuff you're learning.
|
| Finally, and most importantly : it's ok if you're not learning
| as quickly as when you were at university. It's not a
| competition. You have a full time job, don't have a lot of
| time, so just make sure that you enjoy learning, so that you
| keep doing it !
| kbutler wrote:
| Continuing study and investigation after achieving functional
| competence.
|
| Learn more apis, dig in to implementation, read other people's
| code, ...
|
| There's a big difference between engineers who consistently,
| proactively study and learn vs those who just leverage previous
| knowledge.
|
| And I've experienced both sides of that in myself.
| renegade-otter wrote:
| It's possible if you keep things simple, but it's a rather
| naive goal in most places which have already grown in size and
| complexity. Just knowing what's happening with the other teams
| and how your work fits into it is already a full-time job. I've
| spent DAYS on Slack without getting anything done - I had to
| get up early in the morning.
|
| I wrote about something related recently.
|
| "I am not your Cloud person":
| https://renegadeotter.com/2023/07/26/i-am-not-your-cloud-per...
| alex_lav wrote:
| Don't stop learning at the end of your use-case for a piece of
| tech. If your team uses a tool, understand approaches you
| didn't take, trade offs and ultimately why you chose the path
| you chose. Understand even other pieces of tech and their
| approaches. Also, deeply understand failure scenarios and how
| to mitigate them.
|
| Basically just dig in beyond "it works". You'd be surprised how
| many devs never read a tool's docs if they don't absolutely
| have to.
| karol wrote:
| It's the same as the problem of finding a good cleaner. If
| someone is responsible, thorough, turns up on time, has attention
| to detail, can handle delicate objects, is trustworthy around
| children and has good manners - then that person is already too
| good to be an ordinary cleaner and will get hired elsewhere,
| become a manager or a business owner.
| medstrom wrote:
| I don't think the world permits so easy mobility. I have worked
| with cleaners who ticked all those boxes, they were still stuck
| in their job. Meanwhile not all managers tick those boxes.
| Horffupolde wrote:
| It's the eternal paradox of life.
| GreedClarifies wrote:
| A lot of Amazon in that list, that's not a bad thing, one of
| Amazon's greatest strengths is its principles.
|
| Did the author spend time at Amazon?
| cratermoon wrote:
| The only part of this I disagree with is "Couple of years of
| Relevant Practical Experience" is senior. Intermediate, sure.
| Senior should be at least five years AND at least two projects.
| a_square_peg wrote:
| Assuming technical competency is given, I think senior engineer
| really needs to do two things well:
|
| 1. Be able to make a design decision - among multiple options and
| with incomplete data and uncertainties, a senior engineer needs
| to be able to make a decision and be accountable for it in order
| to move the project forward. I think a good interview question
| would be to ask about their difficult design decisions.
|
| 2. Be able to identify wrong solution (most of the time) - maybe
| this comes with technical competency but a lot of resource is
| wasted chasing solutions that with the benefit of experience,
| should have been evident early on.
| shortrounddev2 wrote:
| Mentoring is as important as the technical output. You cannot
| be a senior engineer without being able to mentor
| f1shy wrote:
| I think this is the most important: make the team grow.
| f1shy wrote:
| This HR idea of doing questions abput the past to "know" how
| good somebody will be in the future, is doomed to fail
| kqr wrote:
| Source?
|
| From what I can tell, that is the only good predictor we
| have. See Tversky's work with the IDF or the available CTA
| methods for studying expertise, e.g. CDM.
| beebmam wrote:
| Disagree. A senior engineer should make evidence based
| decisions, as should any engineer. If there's missing evidence
| for a conclusion, then a senior engineer should be able to
| design experiments which gather more evidence to derive a
| conclusion.
|
| Senior engineers should not be con-men.
| CapitalistCartr wrote:
| That sounds great, but hard decisions are hard because there
| isn't time, money, other resources to have all the facts, yet
| a decision must be made. There might not even be any way to
| know for sure without taking one path. Experience is all we
| have to guide us. Progress is full of such decisions, made in
| a gray fog. Fear of being wrong is paralyzing.
| galaxyLogic wrote:
| Exactly. My favorite metaphor for SW-development is playing
| chess. When you make a move, a decision, new choices, new
| decisions to make, open up and other ones may no longer be
| practical.
|
| What you decide and do now, affects what you can and must
| decide next.
|
| Except unlike in chess we don't really have the exact rules
| of the game anywhere. Still we must make choices which
| affect what moves can be chosen later.
|
| It is also like building a house, once you decide how to
| build the ground-floor and what it stands on, that greatly
| affects how the floors above that can be built (not too
| heavy, not too light etc.).
|
| It is often difficult to understand all the consequences of
| a design decision, what can be done and chosen after that,
| until you actually implement that design.
| aYsY4dDQ2NrcNzA wrote:
| Path dependence.
| jldugger wrote:
| > That sounds great, but hard decisions are hard because
| there isn't time, money, other resources to have all the
| facts, yet a decision must be made.
|
| While I am sympathetic to the concept of reasoning under
| uncertainty, the way you've framed it is hardly engineering
| anymore.
|
| Design projects come with a spectrum of data requirements,
| and each has its own cost function for improved accuracy.
| For example, knowing exactly how long the bridge you need
| to build matters greatly, and the cost of surveying should
| be pretty low. In contrast, measuring the soil at the site
| you build on top of has a variety[1] of options with
| varying costs. You can't ever be 100 percent certain that
| your sampling was good enough, but the samples more you
| have the more confident you can be. Depending on the
| project and design, you may not need the most expensive and
| most accurate option, but you probably don't want to just
| rely on priors built through "experience."
|
| Translating this to the world of software, we have a
| variety of data collection strategies. A/B tests, canaries,
| software instrumentation, tracing, offsite monitoring,
| f-scores, beta tests, market surveys, and more. The best
| thing you can do as an engineer making an uninformed choice
| is to design the system to collect the data you are missing
| and to make it easy to change your design later. Amazon
| calls these "two way doors" versus "one way doors"; if your
| decision was wrong you can go back and make a different
| choice. As an example, if you are designing a caching
| system, spending a bit of time to generalize the API will
| allow you to swap between policies as you collect data
| about cache hit rates. If you don't, the cost of changing
| your mind goes up as more things depend on the nuances of
| your API.
|
| Rather valorize making uninformed decisions, I'd prefer to
| valorize flexibility and continuous data collection. Seen
| this way, the old adage "There's never enough time to do it
| right, but always plenty of time to do it over" is a
| coherent philosophy.
|
| [1]: https://en.wikipedia.org/wiki/Geotechnical_investigati
| on#Soi...
| f1shy wrote:
| If you have to make decision, and lack information, time
| and money to even try something to understand the best
| decision, you are having problems bigger than technical
| ones; and even the best engineer in the world will probably
| not do better than a dice
| MAGZine wrote:
| > A senior engineer should make evidence based decisions, as
| should any engineer.
|
| ... sooo there is no distinction between a senior engineer
| and a non-senior engineer? you've really said nothing in this
| comment.
|
| senior engineers have seen enough things to know what the
| right solution is in many cases, without having to take a
| bunch of time to collect evidence. that's what makes them
| senior, not just 'good'.
| f1shy wrote:
| Then the problem is not missing information, as stated.
| There is enough information, if you have enough experience.
| beebmam wrote:
| Disagree, profoundly.
| lowercased wrote:
| > seen enough things to know what the right solution is in
| many cases
|
| When dealing with uncertainty (nearly always) it's
| generally easier to identify and rule out what 'wrong'
| solutions are. There are often multiple obviously 'wrong'
| options (no, we should not keep a user's password in
| plaintext, even if the goal is to make it easy to recover a
| lost password), but picking a 'right' one... from a
| whittled down list, it may often come down to familiarity
| or convention rather than an arbitrary "this is the only
| 100% correct solution".
| stinkbutt wrote:
| A senior engineer should work in an organization that
| actually enables this type of engineering
| paulcole wrote:
| There's _always_ going to be missing evidence. Almost all
| business decisions can be made without 100% certainty. Make
| your conclusion with what you have available and find out if
| that's good enough. Don't dawdle trying to get more info
| that's probably not needed.
| Nevermark wrote:
| An important series of skills would be:
|
| 1. Identify every project dimension with risks. The big one:
| project -> use -> user -> reward -> costumer fit? (Where user
| and customer may, or may not be the same.)
|
| Price cost economics? Technical complexity? Technical
| experience shortfalls? Project resource availability?
| Solution resource efficiency? Safety? Third party
| dependencies?
|
| 2. Identify each significant risk in each risk dimension.
|
| 3. Identify the simplest question (or two) whose answer will
| reduce or eliminate each risk.
|
| 4. If a risk can't be mitigated by answering a single
| question (or two), maybe it is really a combination of risks,
| or risk dimensions. If so break them out, repeat.
|
| 4. Craft the simplest research task to resolve each risk
| question.
|
| --
|
| This sequence is a special case of focusing energy on
| upstream tasks, before investing in downstream tasks.
|
| Or as I like to say: _move slow to move fast._
|
| --
|
| A meta risk is loops in risk/work dependencies.
|
| Classic example: Stakeholder wants to see something working
| before you resolve risks of getting something working.
|
| Identify the simplest, sparsest form of a loop is one way
| forward.
|
| Alternatively, break the loop. Identify alternate ways to
| satisfy the stakeholder. Find a way to remove dependency on
| the stake holder (constructively).
| delusional wrote:
| I can kind of agree with your sentiment. We should run
| experiments, regardless of our skill level. We should, in
| fact, regard anything we do as an experiment. Very few
| decisions in the real world are irreversible. Doing
| experiments doesn't mean there's no skill to it. The Senior
| engineer will know what hypothesis is most likely to prove
| true, and will start with a system design that will work out
| well assuming that hypothesis to be true.
|
| This is what the previous commenter referred to as "making a
| decision without all the evidence". If the senior engineer
| turns out to be right, and the hypothesis proves true, the
| experiment becomes the system. If the hypothesis turns out
| false, the system might still be workable, otherwise it's
| refactored into some new experiment.
|
| The senior engineer is better at making that initial guess as
| the correctness of a hypothesis. Just like a senior
| scientist.
| johnea wrote:
| #61: Shorten the checklist...
| lr4444lr wrote:
| Wow, 60 items and I don't disagree with any of them.
| 29athrowaway wrote:
| There is nothing about engineering in that list.
| Aurornis wrote:
| I've had the good fortune to hire and work with a lot of
| ambitious engineers.
|
| One trap with lists like this is that it can be easy to lose
| sight of your core workload. On more than one occasion I've had
| to ask senior engineers to pump the brakes on all of their
| mentoring, leading, organizing, example-setting, and helping
| activities because their own work was not getting done.
|
| You only have so many hours in a work week. Get your priority
| work done first, then layer in additional activities selectively.
| Don't think you need to be doing all of these things on the list
| all of the time.
| fifilura wrote:
| Then maybe that person has implicitly become a manager.
|
| And to mentor and help others may very well be the best spent
| time for the company as a whole. But then his biggest tasks
| should be done by one of his more junior team-members.
| Longhanks wrote:
| If someone disregards his or her tasks without communication
| to his or her superior, and fails to get the tasks he or she
| was hired for done, a promotion is hardly the right answer in
| my opinion.
| proc0 wrote:
| This is why most software companies tend to ship buggy messes
| that need to be constantly patched and updated. Software
| engineers never get to fully focus on optimizing software for
| the long term because as they gain experience within the org.
| they are moved away from engineering into management of other
| engineers.
|
| I think I get the motivation, an engineer managing a team of
| engineers can achieve "more" in less time. However I put
| "more" in quotes because a single expert engineer can build
| better, faster, and more reliable than an entire team, once
| they have mastered the systems and tools. That will never
| happen if they rarely touch code and instead attend meetings
| to talk about planning and scheduling.
| kbutler wrote:
| It can be hard to accurately measure the value of those
| activities.
|
| You may be getting a short-term benefit at a huge long-term
| cost.
| mellosouls wrote:
| "Understand the business aspect of your work, and what makes
| money. Eventually, only that matters."
|
| Applies only to commercial organisations (and no, even with those
| money is not the be-all and end-all) so not impressive as a
| number one, at least with that wording. Understanding business is
| clearly key though.
|
| TBH that and the rather self-satisfied "it is useful to any
| software engineer, it is especially useful to senior engineers."
| on a rather enigmatic website lacking in other interesting
| writing put me off considering it further.
| dang wrote:
| Discussed at the time:
|
| _Show HN: A Senior Engineer 's CheckList_ -
| https://news.ycombinator.com/item?id=20914236 - Sept 2019 (143
| comments)
|
| (that shouldn't have been a Show HN! too late now)
| quantum_state wrote:
| Great list ... thanks for sharing
| trav4225 wrote:
| I always find advice like this a little confusing. A lot of these
| things seem (to me) to be none of the engineers' business.
|
| To me, engineers receive specs from management and implement
| solutions that meet those specs. And that's it.
|
| I suppose my personal experience must not be how things work
| elsewhere! Kind of fascinating, and it makes me wonder if people
| enjoy all this extra responsibility and how things go when
| engineers disagree with management.
| nuancebydefault wrote:
| Sometimes (often) you feel like following the requirements is
| not the correct way, because they look fine at first sight but
| not so bright when doing a first analysis or design. Then you
| tend to get involved with the "none of my business" business.
| jkaptur wrote:
| It's definitely interesting how people with the same title can
| have such different experiences. I'll try to give the other
| perspective, but please understand that it's a huge topic and
| this is a simplification.
|
| My experience has been an issue is raised - usually by
| management or "the business", but sometimes by engineering.
| "Our website is too slow!". Now _someone_ has to step up and
| clarify things. Like: * what does "fast" even mean for our
| website? It would be great to have an objective metric. * Is
| there such a thing as "fast enough"? * How much time / effort /
| money is a given improvement worth? * How do we prioritize this
| vs. everything else we could be working on?
|
| A project spec comes out of those discussions, but the
| discussions themselves have significant technical and business
| inputs.
|
| I don't view taking part in these discussions as "extra"
| responsibility, I view it as a core part of the job. I've also
| seen what happens when specs are written without technical
| input: it makes implementing them a lot less pleasant.
| proc0 wrote:
| > A project spec comes out of those discussions, but the
| discussions themselves have significant technical and
| business inputs.
|
| Then managers should learn whatever it takes to be able to
| make these types of decisions. There seems to be a double
| standard where engineers have to do all of these non-
| engineering tasks, meanwhile non-engineers never have to
| learn the systems in depth.
|
| I think programming is a hard enough job that warrants 90% of
| focus, at least to be able to reap the benefits of computer
| science. At the dawn of generative AI, we can clearly see
| software has no limits, yet limits are implicitly imposed by
| re-prioritizing an engineer's time with "soft skill" tasks
| and having them spend a huge amount of time thinking about
| things that have little to do with computer science.
|
| If a business needs that specific intersection of skillset,
| perhaps it should be a new role, instead of stretching the
| role of engineering and missing the opportunity to innovate
| at the software level, which in the end would help the
| business anyway.
| iteria wrote:
| What you're talking about to me is mid-level work. Seniors deal
| with ambiguity and feasibility analysis. Non-technical people
| often don't understand the level of tech necessary. They'll
| say, "I want a bridge about this long" very nice, but but did
| you consider the about wind that whistles through this area ?
| Also, how many lanes? Yeah that many is too few because once
| this bridge goes up we're not gonna be reasonably able to close
| it even for maintenance. We need at least 4 lanes. Isn't there
| a cement shortage? Hm.. maybe we can use this material instead?
| No. I don't think building with wood for this length is a great
| idea.
|
| You get the picture. Yes lead developers exist, but they only
| have so much time to do little battles and they're busy making
| sure the big things are arguing correctly. Senior engineers
| should be able to talk to design about a redesign necessary
| because iOS just isn't capable of this it turns out or the cool
| effect you saw is only available on a version we don't use and
| can't update to right because complex reason.
|
| If you're just taking your requirements and working without
| having to negotiate with another person, you're probably not
| doing senior work.
|
| Some of it I the site I don't think is senior work really
| unless you're a tiny shop, but they're not weird since these
| are all skills a for senior adjacent roles that any senior
| might be called on to take randomly. It's not uncommon in many
| shops for leads to be a spontaneous and temporary role for some
| project that disappears on major release.
| donutshop wrote:
| Relevant discussion from the past
| https://news.ycombinator.com/item?id=16367997
| [deleted]
| danwee wrote:
| > Strive for deep technical expertise in technologies used
|
| And that alone occupies most of my (working/free) time. Not sure
| how I'm supposed to keep up with the rest of the list. To know
| technologies is one thing, to have deep tech expertise in many
| technologies is a completely different one.
| tennisflyi wrote:
| Glad number one was explicit. It might not be what you consider
| but for most others it is.
| jameshart wrote:
| Not really a 'checklist'. Can anyone honestly go down this list
| and mark any of the items affirmatively as 'complete'?
| dbalatero wrote:
| No, but you could keep checking in on them and seeing how
| you're doing on a semi recurring basis.
| helpfulContrib wrote:
| You can certainly use the form that way, as your own instance
| of a checklist, and it seems the site has the purpose of
| providing such mini 'applications' in a local-store friendly
| manner - see the Travel checklist on the same site, for
| example.
|
| Pretty nifty, if you think about it. Storage stays local, it
| looks like .. but I am not an expert. I just like the form of
| this.
|
| 3-digit slashdot ID's notwithstanding, I hope we see a revival
| of cute little cottage-/hobby sites like this, or a kind of
| perpetually simple cache of folks who just render their genius
| to static files, in cute ways, and leave it at that... over and
| over for a few years.
| donutshop wrote:
| I agree with this. This is more of a list of reminders to keep
| in mind IMO.
| playingalong wrote:
| I agree with the list and there is nothing wrong with it.
|
| Though, I would like to emphasize this is clearly an Individual
| Contributor kind of a perspective. There are hardly any bullet
| points encouraging building and maintaining work culture, growing
| other people, serving as an example to follow. Maybe a handful
| out of the 60 fall into this bucket.
|
| Thus don't consider this list anywhere near complete if your
| career path envisions being a manager (of different kinds).
| Aurornis wrote:
| > There are hardly any bullet points encouraging building and
| maintaining work culture, growing other people, serving as an
| example to follow.
|
| Well the title is literally about being a "Senior Engineer",
| not a manager. That said, there are numerous bullet points
| about mentoring others, leading by example, and setting work
| culture. Number 18 is "Be a mentor to a couple of junior
| engineers."
|
| > Thus don't consider this list anywhere near complete if your
| career path envisions being a manager (of different kinds).
|
| While you're not wrong, I don't think anyone should expect a
| checklist titled "Senior Engineer's Checklist" to cater to
| management items. A manager's checklist would subtract a lot of
| the IC items from this list.
|
| Management isn't a superset of IC work. It's a different job.
| jameshart wrote:
| There's also some questionable stuff on here for ICs:
|
| > Keep your manager up-to-date on people you have difficulty
| working with
|
| If one of my directs came to a one on one and shared their
| updated enemy-list with me, I'd be pretty concerned.
| cratermoon wrote:
| If one of my directs _didn 't_ tell me about difficult-to-
| work-with people, I'd be concerned. I want to know if there
| are people everyone finds difficult work with, and the best
| way to know is to hear from all ICs.
| alex_lav wrote:
| The fact that you equate "difficulty working with" as an
| enemy list suggests to me you're probably not equipped to be
| managing people. Respectfully.
| jameshart wrote:
| There's a difference between having some awareness of
| interpersonal challenges my team have, versus one of them
| having, among the list of 61 principles by which they
| govern themselves, 'keeping me up to date on who they are
| having difficulty working with'. I mean, I note that there
| isn't a corresponding advice to 'keep your manager up to
| date on people you enjoy working with'.
|
| Overall, it just sounds like they plan on making problems
| and then bringing them to me to resolve. Which, sure, would
| require 'managing'.
| alex_lav wrote:
| > Overall, it just sounds like they plan on making
| problems and then bringing them to me to resolve. Which,
| sure, would require 'managing'.
|
| Yeah...again, I'm trying to communicate respectfully, but
| I really think these perspectives aren't fit for being
| responsible for others' employment.
| jameshart wrote:
| You're clearly a very serious person. It might help you
| to be aware that some other people take things, in
| general, a little _lightly_.
|
| Out of context guidance consisting of little faux-wise
| aphorisms like that of the OP is just kind of inherently
| amusing, especially when offered earnestly, precisely
| because it is open to misinterpretation - and my
| suggestion that it could be interpreted as advice to keep
| your manager apprised of who's currently on your enemies
| list was meant to illustrate that risk.
|
| As putative advice to senior engineers for how to conduct
| themselves, it struck me as something which some toxic
| engineers might take as endorsing their superior
| attitude. That makes it _bad advice_ , and that's why I'm
| mocking it.
|
| But how I react to the idea of this sort of thing being
| offered as career advice, _respectfully_ , tells you
| absolutely nothing about how I conduct myself in my
| professional role.
| alex_lav wrote:
| > and my suggestion that it could be interpreted as
| advice to keep your manager apprised of who's currently
| on your enemies list was meant to illustrate that risk.
|
| Yeah....again....not an enemies list.
|
| > As putative advice to senior engineers for how to
| conduct themselves, it struck me as something which some
| toxic engineers might take as endorsing their superior
| attitude. That makes it bad advice, and that's why I'm
| mocking it.
|
| Yeah...again...this perception is a toxic _manager_
| trait.
|
| > But how I react to the idea of this sort of thing being
| offered as career advice, respectfully, tells you
| absolutely nothing about how I conduct myself in my
| professional role.
|
| We can disagree, that's fine. Thankfully you don't work
| in my organization, so your opinion is of 0 value to me.
| I had (obviously incorrectly) hoped some sane feedback
| might make you reevaluate your behavior, but alas
| stubbornness prevails. Hopefully your reports can manage
| working with you effectively.
| fragmede wrote:
| I... what do you you see as your job as a manager? Your
| entire job as a manager is to manage your direct reports.
| Knowing who they're working with, and who they're having
| difficulty working with (and then to smooth it over so they
| can continue to work together, or move people around so they
| don't have to) is _core_ to the job of managing y 'know,
| people.
| nuancebydefault wrote:
| Zooming in on check 4, ask 'why' until you find the root. For
| some reason I tend to do this almost naturally, with mixed
| results though.
|
| Especially when reviewing code, you often see how things can be
| done more simply, and asking "why" to the reviewee can sometimes
| backfire because of touching a sore point.
|
| Thinking about it, not only when reviewing code. Also, when you
| question the used processes you often bump into "we found out
| from experience this works best" or "why change a working
| process". So always using the "why" tactic can be frustrating at
| times.
| karol wrote:
| Flip prio to high, the list shrinks to 11. Tick all and
| congratulate yourself.
| cratermoon wrote:
| You mean Company impact? I see "effort" and two categories for
| impact - Career and Company. Also I notice that there's nothing
| in the "managers" category that has high company impact. Seems
| about right.
| ChrisMarshallNY wrote:
| _> Resist the urge to refactor major systems to achieve
| simplification, because there 's a risk you will end up with a
| similarly complex system after some time_
|
| Word
| [deleted]
___________________________________________________________________
(page generated 2023-09-10 23:01 UTC)