My friend @orian_sharoni and I are watching David Silver’s UCL course on #ReinforcementLearning
I’ll be posting notes, thoughts and randomness as we watch the lectures.
You can find the slides and video lectures here if you want to dive deeper: davidsilver.uk/teaching/
We meet again, Markov processes!
I can’t remember why I found them so threatening at the uni.
This is an alternate way to think about the state machine from before. I find it easier to wrap my head around infinite trees rather than loopy graphs.
Cons:
- Poor separation of concerns
- May want different error handling per client
- Not all errors can be handled internally
- May be hard to reason about error handling as a whole
A scheme for designing an objective assessment scale for your interview candidates programming work, based on how we graded students work was done at a school I worked at:
1. Decide what’s important for you. That can be:
Working solution, clean code, software design, documentation, professionalism (yes, you can grade that too), understanding requirements.
You can also have bonus points for going “above and beyond” in certain things.
2. Decide what’s the relative weight of each category in your final score.
Now reading Weinberg’s “Introduction to General Systems Thinking”.
Thought I’d try to live tweet some ideas I found interesting as a way to engage with the book.
Abstraction in general (and software design, specifically) is the action of lumping similar things together and giving them the same name.
Using ML jargon, I would say that a system that is “too complex” from design perspective is overfitted to the problem it’s trying to solve.
Opinion: People in our industry are averse to the role of architect because there's a lot of misconception about what an architect actually does.
Not the job of an architect: telling people what classes they should write and let them implement the loops.
The job of an architect: In these three teams, we are working with similar ideas. If we put them under the same category, we will reduce the complexity in the system and will be able to implement our future product plans easily.
To whoever needs to hear this right now: being unproductive in the midst of a global crisis is not a moral failure.
We don’t create our productivity every day out of thin air. We have a lot of support structures in place - some so obvious we fail to recognize them.
Our daily routine. That 5 min venting session when we go and get coffee. The random hallway talk. The alone time on the way home.
It all fell apart now and we need to recognize that and, where possible, find alternatives.
We don’t stress enough the importance of being able to quickly open a new codebase and figure how stuff works.
How to do it:
- Pull out and follow software ‘threads’. Start with something you know: environment variable name, string from the UI, message from the log. Use ‘find in files’ figure out where and how it’s used
- ‘Find usages’ is your friend
- Step the code in debug mode
- Add debug messages (so old school)
- Draw a class/module diagram