Photo by Maria Shanina on Unsplash
During these hard times, please remember that human beings are all equal, but not the same.
In my experience, any tech company you'd call decent company should have the 3 basic points nailed, and cover at least 4 out of the 5 points in each area.
- Psychological safety and a blameless culture
- Fair compensation
- Common-sense flexibility on working hours
Clarity, Autonomy and Collaboration
- Understanding the "why"
- Backlog/roadmap and engineers contributing to it
- Direct communication in solving problems
- Cross-functional collaboration
- Celebrating people taking initiatives
Sustainable Engineering Culture
- Distinguishing between functionally complete vs. ready for production
- Code reviews and testing
- CI and CD or developers deploying to production
- Healthy oncall
- Internal open source
- Technical managers who build trust
- Career ladder
- Parallel IC & manager tracks
- A culture of feedback
- Investing in professional growth
- The software they develop needs to be valuable, usable and feasible.
- There are five properties a team must have in order to be successful in developing working software: empathy, trust, capability, time and feedback.
- The team needs certain safety levels in order to be honest and productive while working together.
- Team members need to balance their work with the rest of their lives.
- Teams have to be empowered to make their own decisions and solve problems.
- Teams should always be learning.
- A healthy team is a happy team.
- Don't plan ahead
- Do the work and wait for recognition to come
- All or nothing outlook
- Undersell yourself
- Who needs a network
- Blame others for things you can control
- Blame yourself for things you can't control
- Get comfortable
STEP 1: Find something you need your computer to do that it doesn't do
STEP 2: Decide some basic details about your goal
STEP 3: Convince yourself that's a possible thing computers can do
STEP 4: Come up with a semi-rational mechanism to implement it
STEP 5: Come up with the most stupid version of the goal you can imagine
STEP 6: sit the fuck down and implement the stupid version
STEP 7: Show the stupid version to someone you respect, and listen
STEP 8: repeat step 5 to 7 with a slightly less stupid version
STEP 9: get help
STEP 10: get stuck
- Prepare for my day
- Helps me manage my stress cycle
- Maintain presence in my interactions with others
- Makes me a better listener
- Recognise when I'm off track
- Recognise when I'm in an emotional state that isn't helping me code
- Especially frustration!
- Have overall better emotional health
- Remember to apply "beginner's mind" when I'm stuck
- Challenge my own assumptions about a piece of code
- Recognise – and deal with – my own inner critic
- Take pride in my achievements
- Keeps me in tune with my values
- Recognise when I'm feeling intimidated by the achievements of others
- Know when it's time to step away from the keyboard
- Meditation is often when I'm at my most creative
- This also helps my learning
- I'm less judgemental when I discover confusing code
- Appreciate the beauty of a fine piece of code
- Decompress at the end of the day
- Prevents me from becoming burned out
- Helps me recover when I do end up on the burnout spectrum
- Be more aware of where on the Flow Cycle
- My productivity is generally higher when I meditate
- I sleep better
- Break it down
- Write a list
- Think about other things you need to do
- Add time for research
- Ready to work!
"In any job I regularly think about whether I'm Learning, Earning and Advancing. I don't stay anywhere if I'm not getting at least two out of three of them."
Rules are good
Thinking is hard. Making decisions is hard. Having some thought-through rules to guide decision helps us be a bit better.
Most of what I learn is useless outside of its immediate context
Focus "learning time" on things that compound
When to use Java or C#
Java is ideal for large enterprise applications. I view C# as a the Microsoft spin on Java.
When to use Python or Ruby
You use them when speed is more important than legibility or debugging. And then Python for ML/AI applications.
When to use a hardcore language
I would maybe use Go/Rust if I was building a fresh web service where latency and performance were more important than community/library support. Haskell or Erlang maybe I would use if I were doing something that required a very elegant or mathematical functional approach without a lot of business logic. I don't know when I would use Clojure – I thnk it'd be if I really came to know and love Lisp. I know that Clojure is a functional paradigm that compiles to JVM bytecode, but I'd use Kotlin for that. Since Kotlin works with Java and also has nice IntelliJ support. Same deal with Scala – I would take Kotlin first.
- Use Typescript instead. It'll make life saner.
- Try to push as much logic as possible to the server. If the front end weren't super complex, I would consider something like Phoenix instead which actually pushes everything to the server.
- Use a framework like Vue or React if you need front interactivity.
- Don't skip unit tests.
When to use C or C++
It seems to be useful for applications like robotics and video games and high frequency trading where the performance gains from no garbage collection make it preferable to Java.
Use PHP or Hack if you want to test server changes without rebuilding
When to make a serverless function
I would use a serverless function when I have a relatively small and simple chunk of code that needs to run every once in a while.
Which database technology to choose
Choose SQL when you need to do ad hoc queries and/or you need support for ACID and transactions. Otherwise choose no-SQL.
When to write a unit test
I try to write a unit test any time the expected value of a defect is non-trivial. But every chunk of code should have a trivial unit test around it. I'm not the guy who thinks that every line and branch must be covered.
When to write an integration test
I try to write an integration test whenever I can't trust the code I don't own
When to write an end-to-end test
- When I don't fully understand how the product works, and can't fully unit test a change, so I want a way to feel a little better that I didn't break everything. Mostly like a "smoke test."
- When I need regression test cases to verify functionality in the case of a future refactor.
- When the results are hard to know ahead of time, for example, doing a complex computation, and I want to test the effects of some code on them.
Case 1 should be avoided, but 2 and 3 you can't really get around.
When to bring on a dedicated support engineer
I've come to believe that as a programmer, you should always advocate for having a dedicated SRE if there's any real risk of after-hours pages that are out of your control.
If you delegate all your IT security to the InfoSec, they will come up with draconian rules
Make the design session about input, not approval
Estimates serve more for creating pressure than for project planning
Be explicit about the difference between hard deadlines, soft deadlines, internal deadlines, and expected completion dates
When somebody says Agile, push for Kanban, not Scrum
Thank you for reading, spread positivity!