Navigation Menu

Skip to content

Instantly share code, notes, and snippets.

@l15k4

l15k4/Random rants on software development.md

Last active December 16, 2017 22:22
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save l15k4/838187b018b70c5f40bc995e997c25eb to your computer and use it in GitHub Desktop.
Save l15k4/838187b018b70c5f40bc995e997c25eb to your computer and use it in GitHub Desktop.
Download ZIP
Raw
Random rants on software development.md

Focus on solving real problems, not virtual problems

  • how wishful thinking works :
    • people tend to do what they like to do and they subconsciously rationalize terrible decisions :
      • let's introduce this foo, bar, baz hyping tech. cause everybody does that these days (it sounds fun)
        • ie. let's use FSM actor with akka persistence (it sounds fun) for a problem that in fact doesn't need any of that
    • use language and platform as a means of solving problems, not the other way around
  • when you live in a world of virtual problems because you subconsciously prefer to solve them over real problems that are not so pleasant to solve, then
    • you're gonna have x responsibilities more to care for with 0 business value unless you are a prodigy programmer
    • unless some business value can be spotted every week, you will end up feeling bad and probably discussing each of your steps with PM(s) whose presence is partially a reflection of your inability to focus on and communicate real problems because you have full hands of virtual problems
    • PMs will have to learn the real problem for you and as a result :
      • cross-team cooperation will suffer because mr X knows only the implementation and mr Y knows the whole problem
        • components get hard to integrate with each other
        • technical debt everywhere -> A cannot change because B cannot change because C cannot change because ^^^

Use Iterative, not Waterfall development

  1. build working solution fast with cleanly separated concerns and imperfect implementations
  2. collect issues, unanswered questions and report missing features in SW you depend on along the way
  3. refactor and churn those imperfect implementations later
  • Otherwise you're gonna end up rewriting expensive perfect implementations/abstractions, unless you are a prodigy programmer
    • remember, you are not writing ScyllaDB where every new piece of code can hurt the system beyond imagination
    • there is nothing harder than refactoring perfect abstractions created in times of weak problem awareness or many unknowns

Testing

  • don't over-test type-safe code, trust more to compiler and yourself (in statically typed languages)

  • code coverage is a corporate KPI bullshit - if you need an explanation of that statement then you don't deserve it

  • TDD helps with problems that are already tackled by Functional Programming

    • use your brain to fully grasp a problem
    • implement a solution to it, ideally using FP
    • write a suite of specifications that must hold for functions that you use
    • improve your solution for it to adhere to those specifications

Never let code reviews set the pace of SW development

  • code reviews tend to lead to slow development of perfect and flawless code but usually to bad designs
    • good designs come to existence by experimenting, prototyping, frequent refactoring, realizing problems and often even rewrites
      • why? Because you get to know much more about the domain and problem later, usually after it starts to be used
      • at that time you will be probably forced to change your perfect and flawless code because of bad overall design
    • you can argue that reviews help with bringing up good ideas but they also prevent you from exploring the possibilities because CRs are time consuming and conservative
  • "ideas & problem solution reviews" sounds much better to me
    • brainstorm good solutions to a problem with others
    • very quickly prototype components without Code reviews or tests, each person different component
    • start using it in staging environment -> find problems and flaws, choose good abstractions and design
    • write it from scratch on a green field with code reviews so that everybody gets familiar with other people's work

Know and like the domain

  • don't do it unless you like the domain
  • unless you spend some serious time on grasping the domain that you build software for, it will probably suck
    • write down everything that is not clear to you and discuss it with someone who knows it or google it instead of operating with blackboxes and asking for detailed specifications or how exactly every single thing should be implemented
  • the problem is that it is out of the comfort zone of opening an IDE and start coding
  • when problem or uncertainty arises:
    • discuss it only at the right place with the right people
    • or come up with a short temporary isolated solution if possible, before the real solution can be introduced

Responsibility

  • there is no cheating or excuse in SW development, only :
    • hard work and success
    • failure
    • slow dying in a world of pain
  • lack of hard work would make you responsible for something you don't know and like
    • either you'd have hard times maintaining it or eventually you'd have to give up and leave it to others to rewrite or maintain it
    • if it is too expensive to maintain, it probably sucks and needs more hard work, more automation
  • if there is almost nothing you are responsible for after years of service, you should probably go vacationing somewhere else

Technical debt

  • never agree to anything that you and other developers would have to bitch about for a decade
    • stand for your beliefs, explain others that it is a big mistake to cripple SW that whole business is built on top of
  • be constantly identifying spots that drag and slow you down and amortize them because there will always be new ones, otherwise :
    • projects start to slowly stagnate until they become a black hole where time and money disappear
    • newcomers won't have a chance to grasp what is going on

Psychology

  • everybody (wolf, sheep and shepherd) has a different strategy and priorities :
    • nerds drink and turn radical
    • family men turn conservative
    • slackers turn liberal (for lack of interest)
  • rules of thumb though :
    • never publicly blow up, it never gets anywhere, it is contra-productive and your mind is not clear
      • blow up privately :-D
    • always know what you want to not burn out, it requires hard work, ie. never stay in state of indecision for a long time
    • always fight for your and the project's well being, eg. road map
    • never be a touchy-feely
      • getting shit done or preventing from disasters requires emphasizing, just saying or writing is sometimes not enough, use brute-force
      • no one has ever built a cool SW while being polite all the time, not even hippies
      • being constructive has its limits because different people have usually different beliefs and they fight for them
      • grow sense for humor, you're gonna need it more and more
    • find the right balance of humbleness and never be arrogant, not even unless :
      • you are 100% sure it is in place in particular context and it may prevent from many further blow ups
      • humbleness of a random slacker is given to you as an example
      • you are currently overworked and you feel entitled to it
      • you have an order of magnitude more responsibilities than someone else
      • your road map does a 180 degree turn within a single month towards a total disaster
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment