5 ms·

I love reading "lessons learned" type posts. The ones I like best here are: #5 Architects make the best decisions when they code. Amen. #10 Appreciate that

I love reading "lessons learned" type posts. The ones I like best here are: #5 Architects make the best decisions when they code. Amen. #10 Appreciate that everyone has different strengths - that's how a team becomes more than its parts. Here are my lessons learned from 25 years of SW development: http://henrikwarne.com/2015/04/16/lessons-learned-in-software-development/ http://henrikwarne.com/2015/04/16/lessons-learned-in-softwar...

tootie 11y ago
Architects coding can be a challenge. I try to write code as often as I can, but I usually don't want to actually take ownership of dev tasks because I usually can't complete them quickly enough with all the demands on my time. Usually in the middle phase of a project when the architecture is set, we've delivered a few sprints and launch is still a little ways away is a good time to dive in for a bit.
- Swannie 11y ago
  I agree. Even when its not coding, I try to take on a technical part of the delivery for myself, particularly a tricky integration that I've got the best knowledge on, or most suitable background to solve. However, like you, I find that I'm often pulled away, and if I invest the time time make what I'm doing of a high quality (walk the talk), I'm typically neglecting higher value tasks. The biggest challenge I have is managers who know you get on the tools, who turn around at crunch time and expect you to dive in and fix issues. Sorry but whilst I am indeed an expert troubleshooter, because I know the architecture, and designed to minimise a lot of these issues, I'm not usually the best person to foresee the impact of my fixes, and again, due to wanting to set a solid example, I don't want to do a hack to fix it, so it takes a quite a long time... when I should be triaging, providing troubleshooting insight, and considering any architectural changes that make whole classes of problems less impacting.
aswanson 11y ago
Those lessons are golden. I've picked them all up along the way, but its worthwhile to verbalize them consciously every few weeks.
JoeAltmaier 11y ago
My definition of Architecture: all that flexibility you build in from the beginning, that you never end up using.
- insulanian 11y ago
  Yeah. I found that generic flexible solutions usually end up constraining me. YAGNI FTW!
- erichocean 11y ago
  My definition of Architecture (from another commenter): making a system that works almost all the time, but when it doesn't, it is not the end of the world, and easily fixable. I spend the vast majority of my time on "architecture" (as opposed to coding) making it so that it's trivial to track down problems in production, trivial to identify the cause once you do, and trivial to deploy the solution once you've made the fix. If you do architecture right, most fixes end up being the moral (if not literal) equivalent of one-liners. At least, that's been my experience. Do architecture wrong (or worse: not at all) and you end up having to rewrite and/or redesign your code entirely, just to identify and/or fix bugs (i.e. not even adding new features).
  - JoeAltmaier 11y ago
    Says every architect ever. Hifalutin words. So what, we build in 'flexibility' - guessing which way we plan on going in a year or two. Then in 6 months we pivot, and find we didn't anticipate that direction.
gav 11y ago
> #5 Architects make the best decisions when they code. It's not just a matter of coding, it's about the right kind of coding. I like to have architects be pareto-programmers, that is they get to 80% of of the solution so that they can hand off the rest to a less-experienced team member. They can solve the hard part of the problem without getting stuck making it productionized and provide an opportunity for mentoring. There's two other code related tasks that are important: code reviews and commit reviews. They give views at different "heights". We have fairly good tooling around the former; I'd love a tool that gave me an email every morning that had X number of random commits distributed over the total committers as best as possible while showing me who hasn't committed for a while.
- Swizec 11y ago
  As a team member, pareto programmers are the worst. They do all the fun interesting work, then raise their hands and push the important work on the team. They refusw to take ownership of their features, create a mess for you to clean up because they certainly missed a detail or two, and just generally suck to work with. The worst is when they say "This is your code man. I'm just helping you out a bit." No. Finish the fucking feature so I can focus on my fucking feature without having to tripple check all your damn work.
  - coredog64 11y ago
    I get your frustration, but I've also seen some pretty bad code where junior developers were given too much freedom to do the "fun, interesting" work. When concerns were raised during pull request reviews, the inevitable answer was "not gonna change it -- approve it now because my sprint is in danger".
    - Swizec 11y ago
      Of course, but my architect is an ex Java guy with 20 years of experience, 2 years frontend. And I'm a guy with 15 years experience, 10 years frontend. Hence much frustration often.
    - 11y ago
digaozao 11y ago
Liked a lot your observations. Specially, the one about bugs. Being capable of fixing fast is really important.
ryanSrich 11y ago
> #10 An age old rule for managers. You can't manage or treat everyone the same. Certain people respond to certain things. That's why great managers are able to really pull the best work out of their employees. They know what drives each one of them.

tootie 11y ago

Architects coding can be a challenge. I try to write code as often as I can, but I usually don't want to actually take ownership of dev tasks because I usually can't complete them quickly enough with all the demands on my time. Usually in the middle phase of a project when the architecture is set, we've delivered a few sprints and launch is still a little ways away is a good time to dive in for a bit.

Swannie 11y ago
I agree. Even when its not coding, I try to take on a technical part of the delivery for myself, particularly a tricky integration that I've got the best knowledge on, or most suitable background to solve. However, like you, I find that I'm often pulled away, and if I invest the time time make what I'm doing of a high quality (walk the talk), I'm typically neglecting higher value tasks. The biggest challenge I have is managers who know you get on the tools, who turn around at crunch time and expect you to dive in and fix issues. Sorry but whilst I am indeed an expert troubleshooter, because I know the architecture, and designed to minimise a lot of these issues, I'm not usually the best person to foresee the impact of my fixes, and again, due to wanting to set a solid example, I don't want to do a hack to fix it, so it takes a quite a long time... when I should be triaging, providing troubleshooting insight, and considering any architectural changes that make whole classes of problems less impacting.

aswanson 11y ago

Those lessons are golden. I've picked them all up along the way, but its worthwhile to verbalize them consciously every few weeks.

JoeAltmaier 11y ago

My definition of Architecture: all that flexibility you build in from the beginning, that you never end up using.

insulanian 11y ago
Yeah. I found that generic flexible solutions usually end up constraining me. YAGNI FTW!
erichocean 11y ago
My definition of Architecture (from another commenter): making a system that works almost all the time, but when it doesn't, it is not the end of the world, and easily fixable. I spend the vast majority of my time on "architecture" (as opposed to coding) making it so that it's trivial to track down problems in production, trivial to identify the cause once you do, and trivial to deploy the solution once you've made the fix. If you do architecture right, most fixes end up being the moral (if not literal) equivalent of one-liners. At least, that's been my experience. Do architecture wrong (or worse: not at all) and you end up having to rewrite and/or redesign your code entirely, just to identify and/or fix bugs (i.e. not even adding new features).
- JoeAltmaier 11y ago
  Says every architect ever. Hifalutin words. So what, we build in 'flexibility' - guessing which way we plan on going in a year or two. Then in 6 months we pivot, and find we didn't anticipate that direction.

gav 11y ago

> #5 Architects make the best decisions when they code. It's not just a matter of coding, it's about the right kind of coding. I like to have architects be pareto-programmers, that is they get to 80% of of the solution so that they can hand off the rest to a less-experienced team member. They can solve the hard part of the problem without getting stuck making it productionized and provide an opportunity for mentoring. There's two other code related tasks that are important: code reviews and commit reviews. They give views at different "heights". We have fairly good tooling around the former; I'd love a tool that gave me an email every morning that had X number of random commits distributed over the total committers as best as possible while showing me who hasn't committed for a while.

Swizec 11y ago
As a team member, pareto programmers are the worst. They do all the fun interesting work, then raise their hands and push the important work on the team. They refusw to take ownership of their features, create a mess for you to clean up because they certainly missed a detail or two, and just generally suck to work with. The worst is when they say "This is your code man. I'm just helping you out a bit." No. Finish the fucking feature so I can focus on my fucking feature without having to tripple check all your damn work.
- coredog64 11y ago
  I get your frustration, but I've also seen some pretty bad code where junior developers were given too much freedom to do the "fun, interesting" work. When concerns were raised during pull request reviews, the inevitable answer was "not gonna change it -- approve it now because my sprint is in danger".
  - Swizec 11y ago
    Of course, but my architect is an ex Java guy with 20 years of experience, 2 years frontend. And I'm a guy with 15 years experience, 10 years frontend. Hence much frustration often.
  - 11y ago

digaozao 11y ago

Liked a lot your observations. Specially, the one about bugs. Being capable of fixing fast is really important.

ryanSrich 11y ago

> #10 An age old rule for managers. You can't manage or treat everyone the same. Certain people respond to certain things. That's why great managers are able to really pull the best work out of their employees. They know what drives each one of them.