- ID
- 5fbaf828-b991-4983-9e23-84314473ae1e
2020-10-20
DONE Journal
CLOSED:
- Note taken on
I finally got the documentation for Workday done today. That felt nice. I had been avoiding it, but happened upon a note from Paul Graham about the importance of writing where he suggests that the hardest thing for people is just starting. So write a rough draft that is not good and then start editing it. So I sat down and just started on something for the docs, and it turns out they sort of wrote themselves. A lot was cribbed from Lattice, to be fair. But I got it done.
In the meantime, the hackathon for our virtual Eng Retreat is supposed to take place tomorrow. I'm a little nervous that we don't have a ton of direction or time to work with Marcin in EEST time.
Silas built a birdhouse with Bubba today using a toolbox he got for his birthday yesterday. He was pretty excited about it, and Bubba made sure he was successful with the project. The more I look at it, I think it might have come out of a kit, but still.
[[id:d71d6a7c-a5c9-41e4-b40c-acbd1afd6aee][One-on-One with Harry]]
<2020-10-20 Tue 9:00-10:00>
[[id:878643e1-c15b-4029-855f-5b2757d6040a][Virtual Engineering Retreat]]
- How can we best share knowledge
+ Bart - There are teams that write good tests, and other teams that don't do it
+ Don't have a straight process that we follow
+ *A lot of things aren't worth sharing*
+ Even API docs, which have a process, don't get followed or updated
+ Ze - Have the doc hub, which combines a lot of links
+ Writing docs have to be a project in and of itself
+ With PLG, if docs and sharing knowledge is side-effect, secondary, not very good at it
+ Out of your time in the week, do you get moments to share something?
+ Mostly in production mode all the time
+ Bart - How are you treating adding docs?
+ Not about finding the time, but treat it as part of the process
+ There are some parts you don't want to do
+ Ze - In our company, we're not all of us strict about having tests in PRs, let along docs
+ Nat - Is there a line between hard and good process?
+ Bart - Generic decisions, you can have different level of decisions about a process
+ We should write tests -- process decision
+ How you write those tests -- finer grained decisions
+ Always enforce we do have tests, question of granularity
+ Gabriel - Find ways to ask about what you're sharing
+ Process of learning must come from yourself
+ If you don't want to learn you wont
+ Nat - bigger problems with current process
+ Colin - Jira commenting on a more regular basis
+ Start or end of day, brain dump what you've been working on
+ Bart - Daily standups, go through context we are currently working on
+ Serves a similar purpose, everyone hears the update,and you provide inputs
+ Bart - Piping python into pyplan, go through slack archives and jira comments
+ We don't have a good way of sharing knowledge about projects
+ Ze - Find out about new things via code reviews
+ We write a lot of business logic
+ Not always excited about new business logic from another squad
+ Our business logic doesn't instill curiosity
+ Rotating teams is the only real way to encourage sharing knowledge
+ Any work outside of business logic, has to come in the context of an INITATIVE
+ We don't find time to work on initatives
+ We're all just django/frontend engineers
+ Don't have hats or positions to push forward ideas
+ Temporary roles, no official role for data architect, rotational roles where you get to focus on arch for two months
+ Chuky - What's the 15Five way of building APIs?
+ Custom API v DRF ... sigh
+ General concensus
+ Gabriel - Some pro/against DRF, result is there is no easy way to fix this
+ Conversation has been brought up a lot, but we end up divided into squads
+ Bart - Jon came up with functional DRF,
+ Actually works to have different conventions depending on what you're working on
+ Tech demos can get boring, not a great way to showcase work
+ Ze - Seeing a little new feature is not so useful
+ Toolbox sessions provide a much better way to learn
+ Like to see Olesky or DevOps guys showing what they do
+ If we all had a few times a year to go deep on something
+ Chuky - PR is a good way to see what people are working on
+ Tech demo is boring, if we have them, should be optional
+ Bart - Cross PRs from another squad, lots of time commitment
+ Context is often missing in what we're working on
- Summary
+ Don't have a straight process that we follow
+ *A lot of things aren't worth sharing*
+ Even API docs, which have a process, don't get followed or updated
+ Out of your time in the week, do you get moments to share something?
+ Bart - Generic decisions, you can have different level of decisions about a process
+ We should write tests -- process decision
+ How you write those tests -- finer grained decisions
+ Process of learning must come from yourself
+ If you don't want to learn you wont
+ Start or end of day, brain dump what you've been working on
+ Bart - Daily standups, go through context we are currently working on
+ Don't have hats or positions to push forward ideas
+ Temporary roles, no official role for data architect, rotational roles where you get to focus on arch for two months
+ Temp process could involve office hours with engineers with deep product knowledge
+ Ze - Seeing a little new feature is not so useful
+ Toolbox sessions provide a much better way to learn
+ Like to see Olesky or DevOps guys showing what they do
+ If we all had a few times a year to go deep on something
+ Bart - Cross PRs from another squad, lots of time commitment
+ Context is often missing in what we're working on
DONE Write up user docs for [[id:48ec7ad9-9d6e-47ec-878e-6d1dce1a830a][Workday Integration with 15Five]]
CLOSED:
DONE [[id:524e3b70-161b-4173-8ee7-a43d725d7273][Running]] 8 [[id:acc626d4-d423-433c-9428-0ac3b5cfc725][Easy Miles]]
CLOSED:
DONE [[id:613d469f-e076-4b42-a880-895bd2ed337f][Nature Talk on Lichen]]
CLOSED:
DONE Make some decisions on Question Playlists
CLOSED: