End of sprint @restartpartners

Been way buried this last three months doing decision making tools for https://restart.us Aka @restartpartners.

Great adventure learning how to write code and get my hands dirty leading a small but amazing group.

Main observations:

Pandemic was great. So many great CS undergrads with nothing to do.
Yet another chapter in the book about how to teach and lead computer software. Great thanks to Sam for teaching me and being patient.
It’s hard to scale and the way people select CS folks these days is really interesting. You learn a lot more from a day of working with someone than a coding test. And heart and character really matter.
There really is a 100x difference in productivity between great and the average coder. Put another way I’d rather have four A players then a dev team of 50 people. Or for that matter ONE world class person that 100 regular folks.
Rewrite a lot. Bring obsessed on how small can you make the code is way better than banging lots of github issues and running sprints. The thing ended up being 3x smaller at the end after tgeee rewrites and could shrink again.
Smaller means fewer bugs and huger performance. Optimization these days is about developer time.
Thanks to John for the “what do you want to do theory of management”. Interest outweighs almost anything else.
Keeping dependencies to a minimum matters. So pick a broad area that’s not overlapping.
Addition by subtraction and reinforce success. Inevitably 20% of the folks won’t work out. It’s a hard call but spending less time with them works because the great folks can rewrite what someone stumbles around in about 100x faster than.
Thinking about people’s careers matters. Because great devs are going to need the right push at the right time. Some need to talk with customers. Some should obsess about details. Individualization is key.
Managers need to write and read code. Ok everyone needs to. Because it’s a craft. And just managing by Lines of code and sprints misses the point. Many times halfway in you realize that it is sll wrong. It’s way better to refactor and fix than live through it.
Copy and paste are truly evil. Even duplication in two places is a disaster. No one ever remembers the second place.
Devcare matters. Spending time on the REPL loop pays huge dividends. A huge 55 inch screen where you can see all the source, debugger and config files in a single Tmux is way more important than anything else.
Allow experiments and failure time. The loop of one week build and one week tech debt is way better than than shamming features.
Don’t listen to bosses and take interrupts. The “zone” is important. Shut off email and slack snd sll those annoying urgent but not important issues.
All projects have one or two critical things that are the crux then the rest is boilerplate. Don’t be afraid of an exponential curve. That is no progress as you figure out the right bets to make and rapidly switch. In our case we changed output engines four times (Excel, streamlit, voila, Jupyter/voila) and it was distressing each time
Software today is about Google-fu, selecting tools and discarding them. If you are writing more than glue code start to worry (coding interviews aside). The biggest skill is looking at three choices and then deciding which way to go in our case it was use numpy or pandas (answer both with a really cool polyglot data type), Google cloud, aws or astronomer.io for data flow (answer none of them the data doesn’t change much so GitHub actions is sll we need).
Getting and knowing a good robust tool is all about the QuickStart, stackoverflow and not about enterprise sales. It’s incredible the number of tools where the QuickStart doesn’t work. And there are no folks online who can help. A hint to all the SaaS companies out there. I’d rather have 1 tech support person who is willing to help fix things than all those annoying CRM chatty spam from an inside sales rep. And who thinks that a 7 day trial is really effective. Let devs build ur deeply into their project before charging.
Never never not write it down snd exoeriment. Thanks to Vlad for this. but have a ‘exp’ part of the project. Run small pieces and write it all dien. Every url u found that helped goes into the code. Every bug is in a README. Finally every installation needs a shell script. And most important everything has a make command.
Reproducibility is key. The biggest mistake I made was relying on virtual environments like pipenv and conda. You get countless problems because they are not right enough. Not to mention if anyone has a windows machine and others have a Mac. Next project is docker from the get go. Yes it’s a pain but do it right once.
Submodules suck but are completely vital. Simple things like putting Makefile includes and all your installs in a lib and bin repo so they work across all projects. And every user having their own personal repo with dot files solves so many problems.
Dev ops as no devops. The best server infrastructure is no server infrastructure. There are so many services now that if ur booting up your own EC2 instance then you probably have not looked hard enough across the cloud vendors. There’s a bespoke service for everything. From Google CI lab to bindery to gitpod to astronomer. For a small early project take advantage. It’s a win to have no server infrastructure at all.
Death to graphical interfaces and remembering menu items. If you don’t check everything in and have to twiddle anything manual ur in trouble. Elbow grease is no substitute for github commits and cli. Yes it takes longer to write something that’s automated but u really don’t want to forget at 2am that u need to check this before doing that.