4 ms·

It is your place to question everything. Your contribution to the team, even if it comes in the form of perspective alone, is valuable anyway.

by maxaf 10y ago

edejong 10y ago
I'd go even further and say that newcomers to teams are often the most able to pinpoint essential flaws in the development process.
- deepaksurti 10y ago
  And that applies irrespective of a newcomer is junior or senior. There is hardly a substitute for a fresh pair of eyes t to reveal what one thinks is cool design, code et al is not so cool after all.
  - JohnL4 10y ago
    We need to distinguish between "I don't understand this and I'm not going to bother to try before I start criticizing" and "Ok, I understand why you did this, but have you considered this alternate approach?" (and maybe "I don't understand this, and I think we need better docs here.", but that's already been covered). (Some) new devs seem to classify themselves into "I'm just a clueless noob" and "I'm the new hotness".
- rimantas 10y ago
  Except often the things pinpointed are not flaws just different from that they are used to.
  - Jtsummers 10y ago
    Then those differences can or ought to be documented. Having fresh eyes on something is good for discovering unwritten processes, rules, etc. If you're doing X because Y, but you never wrote down Y. A new person enters and sees X but doesn't see it's utility (is it better, faster, gives you more robust systems), they may attempt to remove that from the process or tool chain. They may be right, they may be wrong. Because they don't know Y and perhaps no one else in the office does either, at this point. Document the tools you use, why you use them (even if it's just: we were familiar with T1 so we chose it over T2, that's not a bad reason unless T1 has some major flaws or limitations). Document the processes and provide rationales as best you can. This is my viewpoint, at least, as someone who's done a lot of work on the maintenance end of software development. I don't know why in 1984 something was done. I find a particularly gnarly bit of code or process and I want to fix it. Turns out they had a good reason (most of the time), but it's outdated because X. Or it's still relevant, but non-obvious until you get to a certain level of familiarity that only happens for the original developer or a maintainer on the project for 20 years.
  - deleted 10y ago
    [deleted]

It is your place to question everything. Your contribution to the team, even if it comes in the form of perspective alone, is valuable anyway.

by maxaf 10y ago

It is your place to question everything. Your contribution to the team, even if it comes in the form of perspective alone, is valuable anyway.

edejong 10y ago

I'd go even further and say that newcomers to teams are often the most able to pinpoint essential flaws in the development process.

deepaksurti 10y ago
And that applies irrespective of a newcomer is junior or senior. There is hardly a substitute for a fresh pair of eyes t to reveal what one thinks is cool design, code et al is not so cool after all.
- JohnL4 10y ago
  We need to distinguish between "I don't understand this and I'm not going to bother to try before I start criticizing" and "Ok, I understand why you did this, but have you considered this alternate approach?" (and maybe "I don't understand this, and I think we need better docs here.", but that's already been covered). (Some) new devs seem to classify themselves into "I'm just a clueless noob" and "I'm the new hotness".
rimantas 10y ago
Except often the things pinpointed are not flaws just different from that they are used to.
- Jtsummers 10y ago
  Then those differences can or ought to be documented. Having fresh eyes on something is good for discovering unwritten processes, rules, etc. If you're doing X because Y, but you never wrote down Y. A new person enters and sees X but doesn't see it's utility (is it better, faster, gives you more robust systems), they may attempt to remove that from the process or tool chain. They may be right, they may be wrong. Because they don't know Y and perhaps no one else in the office does either, at this point. Document the tools you use, why you use them (even if it's just: we were familiar with T1 so we chose it over T2, that's not a bad reason unless T1 has some major flaws or limitations). Document the processes and provide rationales as best you can. This is my viewpoint, at least, as someone who's done a lot of work on the maintenance end of software development. I don't know why in 1984 something was done. I find a particularly gnarly bit of code or process and I want to fix it. Turns out they had a good reason (most of the time), but it's outdated because X. Or it's still relevant, but non-obvious until you get to a certain level of familiarity that only happens for the original developer or a maintainer on the project for 20 years.
- deleted 10y ago
  [deleted]