Closed MatMoore closed 6 years ago
structuring code and separating concerns
A bit fluffy, but I think the key thing to talk about is the trade-off between making things easy to change in the future, but not so abstract that it's difficult to see what's going on.
how to refactor
I hear Martin Fowler's Refactoring book is a pretty good resource
what we mean by "production ready"
Maybe this should be split up? To me, there are two components of something being "production ready". There's a reliability component, which you meet through design, testing, code review, etc; and there's also a more social component, which is probably best summed up as "if I got hit by a bus tomorrow, no absolutely essential knowledge for operating or maintaining this system would be lost", which you meet through design and code review (again), documentation, ops scripts, and that sort of thing.
automated testing and deployment pipelines vs copying some files onto a server
I think this ties in with the "reliability component" of production ready. It's not the same thing, but having automated testing and deployment is a lot more reliable than someone occasionally FTPing files over.
Maybe this should be split up? To me, there are two components of something being "production ready". There's a reliability component, which you meet through design, testing, code review, etc; and there's also a more social component, which is probably best summed up as "if I got hit by a bus tomorrow, no absolutely essential knowledge for operating or maintaining this system would be lost"
👍 This is a really good idea. It feels a lot more focused than the way we've currently got it. I'm just wondering what to call each thing and which existing competencies this would replace.
Would something like "building software as part of a team" be a better name for this one? Then we could have a separate "designing for reliability" one.
There is another competency we've identified from the career map which which I think could also be covered by this. It currently covers "Participating in the design of technical features" and "Designing systems and setting technical direction for a project or area".
I think "building software as part of a team" and "designing for reliability" are good names.
I've continued this in https://github.com/alphagov/gds-tech-learning-pathway/pull/64
Thanks for the feedback!
Rendered version
This is not complete yet, I just wanted to get some feedback on what I've written.
I'm finding this one difficult to complete, because the original career map doesn't say anything that isn't already covered by "leading on delivering stories", and it touches on a lot of things that we've already got separate competencies for, like security, testing etc.
That said, I think we should definitely cover