What I’ve recently learned and from what.
I’m in no position to comment on most of the things I write about
My solution to this is to think in bets, not outcomes. To clearly notice all of the good bets that I take, the actions that I endorse given what I knew at the time, and to be happy about each of those. And to think of my life in terms of this, rather than the concrete outcomes of the bet, and whether that was a success or failure.
The reality is this profession isn’t that hard, and majority of people working in it are pretty much just plumbers using the innovations of true computer scientists.
don’t panic, and enjoy this whole journey as a learning experience
But now there is no church on Sundays. Just an all-nighter at the startup office. So it’s no surprise that work now feels obligated to tend not just to your needs for making a living, but also for putting all the purpose into that living, since there frequently isn’t room for anything else.
It’s taught me to just try stuff and see if it works; if it doesn’t, the effort is rarely wasted because I likely now have a better idea of what to try next and solid evidence for why this new direction is a better one.
This leads to us never publishing ideas, which is basically the same as never really having the idea at all.
I’ve been a bottom feeder for all these years,” he says. “But there’s a lot of food down there.
I think an org could default to non-blocking and still be easily machine readable. “praise:” also seems a little goofy. Otherwise I love this concept.
- Suggestion: Make intentions known when commenting, by using Labels:. This has a side effect of clarifying tone and limiting misinterpretation.
- Issue: one could interpret you, your as accusatory. This is poison in community projects.
- Suggestion: use we, this where appropriate to create distance between the author and the issues.
Progressively add features while focusing on content and accessibility.
- Go is fast. Our code doesn’t need to be; at least, not at the expense of simplicity.
- Write with minimal configuration, minimal exposed APIs.
- don’t be afraid to repeat code, better than rigidly DRYing which adds complexity
- Don’t use more than one tag per structure field.
- Seperate API / Storage models (API responses don’t need to be an entire user struct)
- Writing the boilerplate takes less time and effort than debugging mapping edge cases
- The important part isn’t the directory structure but how packages and structures reference each other.
Software Dark Ages
Software: Strong emphasis on planning, with events in the User / Data flow. Organize a cause and effect using sticky notes, each constituting an event in the flow. This answers:
- What problems are being solved? (user)
- How are these problems being solved? (engineering)
- What unforeseen issues may arise from the flow? (engineering)
- What steps are critical, what steps are unnecessary? (user)
Iron out complexity until both sides of the table are happy.
Helps align business and development goals. Ensures microservices are in fact micro; adjustments to one feature should not affect the entire system.
Better approach than isolated coding in the basement.
If you need to touch half of the system to implement and test new functionality, your separation is wrong