[Chapter 1] A Pragmatic Philosophy

[janeljs]

A Pragmatic Philosophy

The Cat Ate My Source Code

• responsibility = actively agree
  • suggestions instead of excuses
  • add will find out as pseudo-suffix
• qualms → why dont you change it yourself?
• agency = the ability to take action or to choose what action to take
• http://wiki.c2.com/?ChangeYourOrganization

  You can ChangeYourOrganization (change how the work is done at your current employer) or ChangeYourOrganization. (find a new employer)

• what I related most

  The greatest of all weaknesses is the fear of appearing weak.

• trust in team matters

Software Entropy

• technical debt
  • redemption never happens

    Social psychologists and police officers tend to agree that if a window in a building is broken and is left unrepaired, all the rest of the windows will soon be broken. This is as true in nice neighborhoods as in rundown ones. Window-breaking does not necessarily occur on a large scale because some areas are inhabited by determined window-breakers whereas others are populated by window-lovers; rather, one un-repaired broken window is a signal that no one cares, and so breaking more windows costs nothing.

• never leave legacy codes unattended
• challenges
  • find broken windows
    • select two or three of them and discuss them with team members
    • what is the problem?
    • generate several possible solutions

Stone Soup vs. Boiled Frogs

• facing start-up fatigue
  • conversion to SPA
  • find something that seems insignificant
  • use it as a catalyst for change
  • make people join an ongoing success

Good-Enough Software

Don't spoil a perfectly good program by overembellishment and over-refinement. Move on, and let your code stand in its own right for a while.

• https://ieeexplore.ieee.org/document/382191 Make Quality a Requirements Issue
• challenges
• compare monolithic vs msa, what are pros and cons?
• feature bloat → software maintenance cost increases

Your Knowledge Portfolio

An investment in knowledge always pays the best interest.

• New Concept: expiring assets
• knowledge becomes outdated.
• invest in k-p regularly.
• the habit itself values.
• diversification
• invest beyond technologies you are using now
• enhance adjusting ability (containing english, communication etc.)
• risk management
• balance between conservative and high-risk, high-return
• buy low, sell high
• be a pioneer of an emerging technology
• review and rebalance periodically
• recommended investment items
• learn at least one new (programming) language every year
• action item: start learning kotlin
• read a technical book once a month
• read nontechnical books
• take online classes, conference, etc.
• participate meet-ups - avoid isolation
• experiment with diffrent environments
• stay on top of the latest technology
• cross-pollination → you can expand your mind, even if you don't use it.
• don't stop when you face a question that you can't answer
• use internet, mentor, etc. expand your personal network
• beware of zealots dominated by a particular dogma.
• apply the principles of pragmatism to the document as well Build Documentation In, Don’t Bolt It On Documentation created separately from code is less likely to be correct and up to date.

Book Recommendations

• The Mythical Man-Month
• Peopleware

---

생각정리

• 팀 내 레거시 개선하는 걸 쉽게 보이게 하기 위해선 어떤 돌멩이가 필요할까?
• 필요하지 않는 기능을 구현해놓거나, 사용하지 않는 코드를 그대로 두면 결국 유지보수의 비용이 올라간다. feature bloat의 cost를 항상 염두
• 결국 개발 지식을 학습하는 것도 투자와 같다는 관점. 당장 사용하지 않는 기술을 학습하더라도 결국 사고의 확장에 도움이 될 것이라는 점. 기술에 대한 지식은 outdated 될 수 있지만, 그 지식을 익히는 법, 내 몸에 밴 습관 자체는 asset이라는 점을 기억하자.
• 받아들인 책임-XP
• 내가 모니터링하지 못하는 상황이라도 팀원이 할 수 있도록 문서화해서 공유하기
• 우리 팀원들은 돌멩이와 재료를 구분 못하는 상황이 아닌데???
• 변화의 촉매 - 긍정적 이탈 - TDD
• 애자일 - 1년을 기다리는 것보다 당장이라도 불편한 소프트웨어를 제공하는게 낫다. (훌륭 vs 완벽)