Error handling approaches 🧵:

You are writing a component, the component may generate errors. What are some common patterns for handling these errors and the pros and cons of each? Throwing exceptions.
Pros:
- Language support and enforcement
- Unified method to handle all types of errors
- Handle only where must

Cons:
- May not be part of interface
- Hard to reason about flow
- Error handling code may be everywhere
- Cannot enforce correct handling

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/

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.

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.

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.

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

I like that.

@yevk75 - he’s smart, sensitive, supporting and kind. Talking to him brings out of you the best version of yourself.

https://twitter.com/sarah_edo/status/1160146506902646784

@dafnaros - is a force of nature. She moves mountains.

Go read Rina's post about error handling.

https://twitter.com/rinaarts/status/1096808458576453632

Personally, coming from the Scala school of programming, I'm partial to data types that express the fact a computation can return an error in the type system (such as Try and Future).

My dream project management tool:
- Can manage tasks in different views
- Hierarchy view: collapsible, so that I can get a big picture of the project and drill down when I need to
- List view: For backlog management and prioritisation - Architecture view: I want to be able to associate each task with a part of an architecture diagram, and have all the relevant parts highlighted when I select a task / part of the tree

What you choose to focus on in the early days of your company/product shapes them in fundamental ways.
This is why I believe being intentional about your choices is important. The people who found the company shape the kind of company it’s going to be. A biz person, a marketing person and a UX person will build a vastly different product from a tech person and an NLP person, even if the problem domain and even the problem itself is the same.

When you talk about your career, consider how your word choices affect the way you are perceived. Did you lead a project? Say it!
You didn’t “take part” in it. You had a central role in its success. It’s your accomplishment. Own it.

I sometimes think about how much the software world has changed in the past 10 years.
It used to be so hard for me to maintain a professional network, and now I have a pretty decent one. And it’s not because I became better at the task of networking in a male-dominated field.
It’s because there are so many amazing organizations out there who focus on creating alternative women-centric networks.
It’s so much easier when you belong.

Two skills with the worst/best importance+usefulness/glory ratio are writing new code vs. maintaining existing code. Starting a project from scratch is one of the most glorified and sought after tasks of our profession.

Tip for junior devs: learn to read and analyze other people’s code. Do it purposely. It’s a critical skill that’s not taught often enough, many devs struggle with it and it makes a tremendous difference in results.