Chapter-1.md

A Pragmatic Philosophy

• It is your career, your life. You own it.
• It is an atitude, style, a philosophy of approaching problems and their solutions.
• The Cat Ate My Source Code - Take responsibility.
• Software Entropy - Importance of not having the 1st broken window in your code.
• Stone Soup and Boiled Frogs - Importance of big picture and need for change.
• Good-Enough Software - When can we say a software is good enough with necessarry trade-offs.
• Knowledge Portfolio - Keep learning and how to keep the momentum for the same.
• Finally Communicate!

It's Your Life

• You own it. You run it. You create it.
• Developers being frustrated with varying concerns about stagnating in job, work loction or being backward in technology front.
• Why can't you change it?
• You have more agency working in software development career.
• Work for what you want, do not resist change and be proactive.

The Cat Ate My Source Code

• "The greatest of all weaknesses is the fear of appearing weak".
• Do not be afraid to admit ignorance or error.
• Take charge of your career advancement and learning.
• Things go wrong inspite of thorough testing, documentation and automation.
• Must own up to our shortcomings - our ignorance and our mistakes.

Team Trust

• Team Trust is important and everyone should be comfortable replying on others where needed.
• Trust allows us to be open and honest, speak our mind and present our ideas.

Take Responsibility

• In addition to making ourselves accountable, analyze the situation for risks that are beyond control (there always will be).
• Have contigency plan for the risks identified.
• When a mistake is made, admit honestly.
• Instead of excuses offer alternatives or options.
• Don't blame anyone or anything.
• There is nothing that can't be done. Find the way and costs associated with it.
• "You have the right not to take responsibility for an impossible situation, or one in which the risks are too great, or the ethical implications too sketchy. You’ll have to make the call based on your own values and judgement"

Challenges

• How do you react when someone - such as a bank teller, an auto mechanic, or a clerk-comes to you with a lame excuse? What do you think of them and their company as a result?
• When you find yourself saying, "I don't know," be sure to follow it up with "-but I'll find out." It's a great way to admit what you don't know, but then take responsiblity like a pro.

Software Entropy

• Entropy - Amount of disorder in a system
• Naturally, entropy is bound to increase.
• Technical debt is just an optmistic term we use to give us an notion that we will work on it someday. We won't.
• Project Pyschology being one major factor that contribute to technical debt (or) software rot
• Projects with best plan and people experience ruin and projects with enormous difficulties and constant setbacks come out pretty well at end. Why?

Broken Windows

• Analogy of an building which starts to deteriorate - it all starts with 1 broken window.
• A broken window left unrepaired gives a false sense of abondonment until it becomes real.
• Hopelessness can be contaigious in a community and in a team creating a vicious spiral.
• Broken window in software - bad designs, wrong decisions, poor code
• Neglect accelerates software rot faster than any other factor.
• Take some action to prevent further damage.
• Get a dumpster and trash what is not needed, fix what is needed.
• Cause no additional harm.
• One bad decision that the team needs to live with is all it takes for decline.
• It's all about the mindset - when everything is good in the project, no one wants to be the first to make a mess. On contrary, when there is already a lot of broken windows, you know what happens.

Challenges

• What are the broken windows in your projects? What can be done to fix them?
• Can you tell when a window first gets broken? If it is due to someone else decision, what can you do about it?

Stone Soup and Boiled Frog

• Story of the Stone Soup
• Is it manipulation or deception? Is it similar to what we might call office politics?
• "It's easier to ask for forgiveness than permission"
• "People find it easier to join an ongoing success"

Be a catalyst for change

The negative side

• Things just creep up on us.
• Projects slowly get totally out of hand. Most software disasters start out too small to notice. Systems drift from their specs feature by feature.

Remember the Big Picture

Boiled Frog

The authors of this book didn't try it but an author of another book did. :)

• Opposite problem to that of what we saw in Software Entropy.
• "Keep an eye on the big picture. Constantly review what's happening around you, not just what you are personall are doing."

Challenges

• Are you causing benefit or harm?
• Without looking, how many lights are in the ceiling? How many exits in the room? How many people? Get in the habit of really looking and noticing your surroudings.

Good-Enough Software

• Order of 100,000 IC chips 1 in 10,000 are defective. Imagine you get 1 large box with thousands of ICs and 1 small one with 10. Does this ever happen?
• The defects in your software does not show up itself and say here I am!
• Time, technology, and temperament all conspire against us to provide a perfect software.
• Good enough for your = More productivity and happier users
  • Users
  • Future maintainers
  • Own peace of mind
• Good enough != sloppy or poorly produced code
• All system should meet
  • user requirements
  • basic performance, privacy and security standards
• We need to make our users understand that "everything cannot be perfect and there are always tradeoffs"

Involve Your Users in the Trade-Off

• We usually focus on "what" they want but not on "how" good they want it to be?
• Give your users opportunity to decide what is good enough for their needs.
• Let them choose the tradeoffs - of course with a lot of explanation
• Sometimes there are no choices or tradeoffs to make and that is ok
• With marketing promises, end user plans based on delivery schedule and company's cash flow constraints, it is unprofessional to promise impossible time scales and cut basic engineering corners to meet a deadline.
• Discuss the scope and quality of the system you produce as part of system requirements

Make Quality a Requirements Issue

• Great software today is often preferable to a fantasy of a perfect software tomorrow

Know When to Stop

• Programming is like painting, the painting becomes lost in the paint.
• Your perfectly good program may not be perfect, it could never be
• Do not get into the feature loop.

Challenges

• Look at the software tools and OS you use. Can you find evidence that these organizationa and their developers are comfortable shipping software they know is not perfect?
  • As a user would you rather,
    • wait for them to get all the bugs out
    • have complex software and accept some bugs
    • opt for simpler software with fewer defects
• Consider the effect of modularization on the delivery of software. Will it take more/less time to
  • Get a tighly coupled monolithic software to the required quality (or)
  • System designed as a very loosely coupled modules or microservices
  • Advantages and Disadvantages of both?
• Think of a popular software that suffers from feature bloat. Are you in danger of falling into this trap yourself?
  • Feature bloat - containing more feature than you would ever use introducing more opportunity for bugs and security vulnerabilities

Your Knowledge Portfolio

An investment to knowledge always pays the best interest - Benjamin Franklin

• Your knowledge and experience are your most important day-to-day professional assets
• Unfortunately these are expiring assets - knowledge with new technology/language/environment and experience with new market need
• Managing a knowledge portfolio is similar to managing a financial one
  • Invest regularly
    • Invest regularly, even if small amount
    • Consistent time and pace, away from interruptions
  • Diversify
    • More different things you know, the more valuable you are.
    • You need to know the ins and outs of your current technology, but don't stop there
    • The more technologies you are comfortable with, the better you will be able to adjust to change
    • Don't forget the non-technical skills you need
  • Manage Risk
    • Technology - Risky, potentially high-reward -> low-risk, low-reward standards
    • Don't put all your eggs in one basket
  • Buy low, sell high
    • Learning an emerging technology might be challenging but it pays off well, rewarding
  • Review and rebalance
    • Brush up old skills if needed, review they why's of what you are learning
• This is a skill which can be learned but you need to make it a habit to manage your knowledge portfolio

Invest Regularly in Your Knowledge Portfolio

Goals

What's the best way to acquire intelligence capital to fund your portfolio? Suggestions:

• Learn a new language every year
• Read a technical book each month
• Read non-technical books, too
• Take classes
• Participate in local user groups and meetups
• Experiment with different environments
• Stay current

It doesn't matter if you ever use these technologies. The process of learning will expand your thinking. Even if your project doesn't use that technology, you can borrow some ideas.

Opportunities for learning

Someone asks you a question and you have no idea. Don't give up! Take this as an opportunity to learn. Find the answer, ask around, search the web, find out who might know the answer.

This takes time, so plan.

Critical Thinking

You need to ensure what you're learning is accurate. Don't be swayed but think critically.

Critically analyze what you read and hear

• Ask the "Five Whys"
• Who does this benefit?
• What's the context?
• When or Where would this work?
• Why is this a problem?

Challenges

• Start learning a new language this week.
• Start reading a new book. Read a book that complements what you're doing now.
• Get out and talk technology with people outside your current work/project.

Communicate!

I believe that it is better to be looked over than it is to be overlooked - Mae West, Belle of the Nineties, 1934

• It's not just what you've got, but also how you package it.
• A good idea is an orphan without effective communication.
• As developers, we
  • Communicate our intentions to a machine via a programming language
  • Document our thinking for future developers
  • Status report, suggest new approaches
• We all know we spend a good amount of day in meetings, talking, listening to others.

English is Just Another Programming Language

Know Your Audience

• Talking and Communicating are 2 different things.
• You're communicating only if the reciever recieved what you expect them to recieve.
• Needs, capabilities and interest of the audience is of paramount importance.
• Know what your audience wants and align it with what you want to communicate.
• The same enhancement would need to be communicated in different ways to end users, marketing, managers and finally developers.
• Look for body language, facial expressions and ask for feedback
• Improve the knowledge of your audience and apply it in your communication

Know What You Want to Say

• Working out what we want to say is most challenging part of formal communication
• For developers, things tend to flow directly from their heads to meetings and documentation
• We need to plan what we want to say by
  • Write an outline
  • Ask "Does this communicate what I want to express to my audience in a way that works for them?"
  • Refine it until it does
• Above needs to be done for both meetings and documentation
• Plan strategies on how you can influence and do some convincing if needed. It is important here we think about "What's in it for them, the reciever?"
• Deliver what your audience wants as you would have discovered it in previous step.

Choose Your Moment

• Make sure what you're saying relevant in time, as well as in content.
• A manager who's just been given hard time by her boss because some source code got lost, would be a receptive listener to your ideas on source code repositories.
• Always ask the question "Is this a good time to talk about ... ?" wither to the reciever or sometimes to yourself.

Choose a Style

• Consider the style of communication the reciever would usually prefer
• "Just the facts" briefing
• Long, wide-ranging chat before getting down to business
• Skill level - Newbies, expert
• Do they need handholding or just a quick TL;DR
• If in doubt on any of the above, just ask.
• Be open to giving feedback if you think you cannot satisfy the expectations of the reciever.

Make it Look Good

• Ideas need a good looking vehicle to convey them to your audience.
• You can slave in kitchen, only to ruin your efforts with poor presentation.
• Developers and managers are solely focussed on only the content of the document.
• Use style sheets, check sample documents that use them, check spelling automatically and then manual.
• Know how to format your document, set headers and footers.

Involve Your Audience

• You can involve your audience once the inital draft of the document is ready
• Get feedback on the draft, ask questions
• Builds the relationships and produces better documents in the process

Be a Listener

• 1 technique to make people listen to you - Listen to them.
• Even if you know it all, listen to them.
• Encourage people to talk by asking questions, restate the discussion.
• Turn the meeting to a dialog, make it interesting and you will make your point.
• You might learn something new.

Get Back to People

• How will you feel if you ask somene a question and they didn't respond.
• Same applies to emails you recieve.
• Respond to emails in your busy life even if its "I'll get back to you later"
• Keeping people informed makes them feel you haven't forgotten them.

It's Both What You Say and the Way You Say It

Unless you work in a vacuum, you need to be able to communicate. The more effective it is, the more influential you become.

Documentation

• Unfortunate necessity, treated as low priority task that management will hopefully forget at end of the project.
• Keep documentation close to code, as comments.
• Add comments not to each and every line which makes it painful.
• Comments should cover only the Why part as the How is evident (violation of DRY principle).
• Good comments tell you about engineering tradeoffs, why decisions were made, alternatives discarded.

Challenges

• Books to read in next 18 months
• The Mythical Man-Month
• Essays on Software Engineering
• Peopleware: Productive Projects and Teams
• Dinosaur Brains: Dealing with All Those Impossible People at Work
• Next time before you do a presentation, writing a email try working through about advise.
• Talk to your audience later and check how good your assessment was.

Online Communication

• Everything offline applies to online too
• Emails are main form. Some tips:
• Proofread before you hit SEND
• Check spelling, unwanted auto-corrections
• Quoting previous email should be minimum not to just reply back with "I Agree"
• Quote inline if necessary
• If you would not say it to their face, don't say it online
• Check list of CC before sending
• Email is same as a written memo or report. Give it the same importance. They are proofs!

<- README