Software How-To
**iteration**

A podcast about development and design.

We do our best to be code-agnostic but we talk a lot about Rails, JavaScript, React, React Native, design, business and startups.

Latest Episodes:

Time and Simplicity Jun 22, 2018

Show notes

Chapter 5 (Part 2) - Bend Or Break

A weekly podcast about programming, development, and design through the lens of amazing books, chapter-by-chapter.

Tip 40: Design Using Services

JP: This is spoken in the context of concurrency (going back to temporal coupling); These service objects are behind well defined interfaces
John: "services—independent, concurrent objects behind well-defined, consistent interfaces."

Tip 41: Always Design for Concurrency

JP: Thinking linear-ly leads to assumptions and sloppy code and mysterious bugs. Concurrency gives you flexibility
John: concurrency forces you to think through things a bit more carefully—you're not alone at the party anymore.

Tip 42: Separate Views from Models

JP: Separate your data from your view logic. This buys you a lot of flexibility. You can use common viewers on many different data models. You can support multiple controllers to provide nontraditional input. Your model encapsulates your data and all the common operations with manipulating it.

The view is an interpretation of the model. It doesn't need to be graphical. The controller is more of a coordination mechanism, and doesn't have to be related to any sort of input device.

John: Each view should have its own controller.
John: Debugging View - interesting concept.

Tip 43: Use Blackboards to Coordinate Workflow

JP: Use blackboards to coordinate disparate facts and agents, while maintaining independence and isolation among participants
John: The blackboard style of programming removes the need for so many interfaces, making for a more elegant and consistent system.
John: "Feed" concept

Picks

JP: Programming Elixir by Dave Thomas

Seriously... just look how cool this is.

defmodule MyList do
  def flatten([ [sub_head | sub_tail] | tail]) do
    flatten(sub_head) ++ flatten(sub_tail) ++ flatten(tail)
  end

  def flatten([ head | tail]) do
    flatten(head) ++ flatten(tail)
  end

  def flatten([]), do: []

  def flatten(head), do: [head]
end


IO.inspect MyList.flatten [ 1, [ 2, 3, [ 4 ] ], 5, [ [ [ [ 6 ] ] ] ] ]
# [1, 2, 3, 4, 5, 6]

John: Sketch Mirror + Sketch Prototyping

Bend or Break Jun 15, 2018

Show notes

Chapter 5 - Bend Or Break

John: Welcome to Iteration: A weekly podcast about programming, development, and design through the lens of amazing books, chapter-by-chapter.

Quick update: Sketch Color Spaces

Today we'll be going through Chapter 5, "Bend or Break" - where we talk about writing flexible code. This is especially important for software engineers in a profession where things are constantly changing. (insert joke about JavaScript frameworks). We will largely focus on different ways we can decouple our code!

Life doesn't stand still. Neither can the code that we write. In order to keep up with today's near-frantic pace of change, we need to make every effort to write code that's as loose—as flexible—as possible.

Part 1 Tip 36: Minimize Coupling Between Modules

Organize code into modules and limit interaction between them. If one module gets compromised and has to be replaced, the other modules should be able to carry on.

Avoid coupling by writing shy code and applying the law of Demeter

What is shy?

JP: shy doesn't reveal itself to others and doesn't interact with too many people. write shy code. you don't want this: selection.getRecorder().getLocation().getTimeZone()
John: What does this loo lie practically? Short methods? How do I avoid "coupling?"

Tip 37: Configure, Don't Integrate

Implement technology choices for an application as configuration options, not through integration or engineering

JP: algo choices, database products, middleware -> these should be configuration options. doing so makes our code more flexible. this is described as "soft" - aka easy to change
John: Example: Platform fee, or simple basic shared defaults.

Tip 38: Put Abstractions in Code, Details in Metadata

Program for the general case, and put the specifics outside the compiled code base

JP: think declaratively - not imperatively. specify what, not how. Think about how you write your business logic and business critical things. Think about where you would call these functions or methods. it should be declarative
John: leave the details as soft—as easy to change—as we can. - "Weekend" automated emails example - valid_send_days
John: Challenge from book: For your current project, consider how much of the application might be moved out of the program itself to metadata.

Tip 39: Analyze Workflow to Improve Concurrency

Exploit the concurrency in your user's workflow

JP: temporal coupling - aka coupling in time - aka thinking linear-ly. Decouple your time / order dependencies. ask yourself: what can happen at the same time?. This is a good thought experiment

This example was really good so I'm copying it from the book:

making a pina colada

1 open blender
2 open pina colada mix
3 put mix in blender
4 measure 1/2 cup white rum
5 pour in rum
6 add 2 cups of ice
7 close blender
8 liquefy for 2 mins
9 open blender
10 get glasses
11 get pink umbrellas
12 serve pina coladas

Think about how imperative this is. First do this... then do this...

BUT, think about what you can do concurrently: 1, 2, 4, 10, 11. These can happen all at the same time and up front. Next, 3, 5, and 6 can happen concurrently afterwards. These would be big optimizations

Picks

JP: Pocket Developer Die
John: AppSignal - Dropped Rollbar + Scout for this one service.

Pragmatic Paranoia Jun 08, 2018

Show notes

Chapter 4 - Pragmatic Paranoia

Tip 30: You Can't Write Perfect Software

perfect software doesn't exist
"defensive driving" analogy
for a programmer, you shouldn't trust YOURSELF either, haha

“Pragmatic Programmers code in defenses against their own mistakes.”

John: To me this means testing and never assuming the user is wrong.

Tip 31: Design with Contracts (long section alert)

https://github.com/egonSchiele/contracts.ruby

"You can think of contracts as assert on steroids"

This says that double expects a number and returns a number. Here's the full code:

require 'contracts'

class Example
  include Contracts::Core
  include Contracts::Builtin

  Contract Num => Num
  def double(x)
    x * 2
  end
end

puts Example.new.double("oops")

be strict in what you will accept before you begin, and promise as little as possible in return. Remember, if your contract indicates that you'll accept anything and promise the world in return, then you've got a lot of code to write!

What is a "correct" program?

“What is a correct program? One that does no more and no less than it claims to do. Documenting and verifying that claim is the heart of Design by Contract”

idea of "designing by contract" - a program should do more and no less than promised
this is kind of like testing. Ruby doesn't have a "contract" system built into its design
obviously, we have a Ruby gem for it! hah
the reason this is supposedly more powerful than plain ol assertions is that contracts can propagate down the inheritance hierarchy
given some precondition that must be true (i.e. must be a positive integer) -> the postcondition will be satisifed

Tip 32: Crash Early

don't have, "it can't happen mentality"
code defensively
a pragmatic progammer tells themself that if there is an error, something very bad has happened
err on the side of crashing earlier! - when you don't, your program may continue with corrupted data

“It's much easier to find and diagnose the problem by crashing early, at the site of the problem.”

John: In ruby using rescue to aggressively just pushes the problem up. Not crashing but not working properly.

When your code discovers that something that was something to be impossible just happened, your program is no longer viable

A dead program normally does a lot less damage than a crippled one

this brings into discussion being able to handle errors gracefully - this is very much a UX question as well

Tip 33: If it can't happen, use assertions to ensure that it won't

"This application will never be used abroad, so why internationalize it?"

Let's not practice this kind of self-deception, particularly when coding

this cuts me deep
when you're this confident, you should write tests to absolutely ensure that you're right

John: Write tests prove it won’t be used in a certain way.

I assumed there would always be money in the stripe account.
Think through how the world will screw things up. Write tests against it.

Tip 34: Use exceptions for exceptional problems

our good friend, the javascript try...catch - ask yourself: "will this code still run if I remove all of the exception handlers". if the answer is, "no" then maybe exceptions are being used in nonexceptional circumstances

John: Error and an exception are two different things. Very loosely: one is based on incorrect inputs the other is an error in a process.

Programs that use exceptions as part of their normal processing suffer from all the readability and maintainability problems of classic spaghetti code. These programs break encapsulation routines and their callers are more tighlting coupled via exception handling

Tip 35: Finish what you start

John: Garbage collection. We are lucky as most major frameworks do garbage collection for us.

resources that devs manage: memory, transactions, threads, files, timers
these resources need memory allocated, THEN deallocated
the problem is that devs don't have a plan for dealing with allocation AND deallocation
basically, don't forget to garbage collect
not doing so may lead to memory leaks
don't forget to do things like close files

John: I currently have this problem with action-cable web-socket connections. I am opening them and not managing the closing of these connections well. So it’s leading to performance issues.

Email sending: make sure it delivered. Handle the exception, finish what you started!

Picks

John: Rails Conf Talks are live I will update with my blogpost of top picks here. Polymorphism

Prove It. Jun 01, 2018

Show notes

Stubs/doubles vs mocks

Stub is simple fake object. It just makes sure test runs smoothly.
Mock is smarter stub. You verify Your test passes through it.

Good stack exchange link on this

Tip 26: "select" isn't broken (debugging strategies)

tracing
rubber ducking

JP: "what does your program think is going on": DON'T BLAME EXTERNAL FACTORS FIRST. It's probably your code haha!

John: why, when faced with a "surprising" failure, you must realize that one or more of your assumptions is wrong.

Tip 27: Don't assume it - prove it

JP: "routine" code isn't infallible! did you test all of the edge cases?

I really like the debugging checklist so here it is:

Is the problem being reported a direct result of the underlying bug, or merely a symptom?
Is the bug really in the compiler? Is it in the OS? Is it in your code?
If you explained this problem in detail to a coworker, what would you say?
If the suspect code passes its unit tests, are the tests complete enough?
Do the conditions that caused this bug exist anywhere else in the system?

John: Duplicate the problem in tests.

Tip 28: learn a text manipulation language

examples of text manipulation:

generating web docs
test data generation
book writing
etc

JP: Funny enough, Hunt and Thomas like using Ruby (and Perl) to quickly hack short scripts

John: I want to push more into this - Just barely experimenting with self-creating API docs. Even just things like in ruby: writing a rake task to pull out all your custom objects and methods to start docs and get a clear picture has been helpful for me.

Tip 29: Write code that writes code

passive vs active code generators

passive = run once to produce a result
active = run every time you need a result. results are then thrown away

JP: meta programming? code gen doesnt have to be meta

John: Refactoring methods to "Find common resources" based on "Model" name - Reducess code significantly.

Picks

JP: Sergei Rachmaninoff: Piano Concertos Nos. 2 & 3. Good classic music
John: iOS Keyboard push down trick

RANDOM LINKS MENTIONED! 🎉

...a poor craftsman blames his tools May 25, 2018

Show notes

Chapter 3 - The Basic Tools

Every craftsman starts his or her journey with a basic set of good quality tools

Discussion: What are your tools?

Tools become conduits from the craftsman's brain to the finished product - they have become extensions of his or her hands

Always be on the lookout for better ways of doing things

Tip 20: Keep Knowledge in plain text

JP: plain text doesn't become obsolete - as opposed to binary. this seems obvious. this is mostly about readability

Tip 21: Use the power of command shells

JP: you can do everything in the shell that you do using the GUI: launch apps, browsers; search files; touch, mkdir, rm -rf. basically i need to get better at this. touch newfile.rb is faster than right click > new file > newfile.rb > carriage return

Tip 22: use a single editor well

JP: fuck IDE's, VIM all the way, baby!!! I no longer rely on auto complete and it's amazing. The editor is an extension to your hand

Tip 23: Always use source code control

JP: the front end devs at my job don't check their files into git and it blows my mind.

Tip 24: Fix the problem, not the blame

JP: "it doesn't really matter whether the bug is your fault or someone else's. it is still your problem". suck it up!

John: There is no User Error - The design of everyday things. - Industrial deaths.

Tip 25: Don't panic when debugging

JP: don't waste energy denying that a bug is possible. clearly, it is. just breathe

Picks

JP: Grit by Angela Duckworth & this Adam Cuppy Talk
John: Swappa - Buy and sell used tech and refurb.me

I'll get back to you... May 18, 2018

Show notes

Chapter 2 - A Pragmatic Approach

Tip 16: Prototype to learn

JP: I love doing this during "exploration" - careful not to use prototypes in prod 👀

John: prototype vs tracer bullet - Expectations: Remind them that you can build a great prototype of a new car out of balsa wood and duct tape, but you wouldn't try to drive it in rush-hour traffic! - Localhost with ngrok

Tip 17: Program Close to the problem domain

JP: Remember to focus on domain problems and not petty implementation details

John: Let your code be english! - Let it reflect the way your team talks. execute_email_delivery_protical vs send_email

Tip 18: Estimate to avoid surprises

JP: Be deliberate and keep track... wording is key (i.e. specificity)

John: Reality - scope is a Moving target - Tracer code and testing helps make sure estimates are well thought out. Charge to estimate / mockup.

Tip 19: Iterate the schedule with code

JP: Keep an open line of communication about expectations for scheduling

John: What to say when you are asked for an estimate "I'll get back to you" - Scope can be revised. Not just timeline.

Picks

JP: - Todoist
John: text expander - TextExpander lets you instantly insert snippets of text from a repository of emails, boilerplate and other content, as you type.

Tracer bullets May 11, 2018

Show notes

Chapter 2 - A Pragmatic Approach

Overview = combine ideas and processes

duplicate knowledge throughout systems
don't split any one piece of knowledge across multiple system components (orthogonality)
insulate projects from their changing environments
gather requirements and implement code at the same time
how to give project estimates

This chapter is truly about a "pragmatic" approach to development

Tip 11: Don't Repeat Yourself

if you change one, you'll have to change another

Duplicated code arises differently:

imposed: devs feel they have no choice
inadvertent: devs don't realize they are duplicating
impatient: devs got lazy because it seems easier
interdeveloper: multiple people on a team duplicate a piece of info

we call these the "four i's"

"shortcuts make for long delays"
number 4 is a result of large teams - not having a --- dare I say --- a ubiquitous language
you need good communication to quell number 4
READ DOCS
Tip: Lean on code and programmatically generated things to prevent repeating yourself.

Tip 12: Make it easy to reuse

you want to create an environment where it's easier to find and reuse existing stuff so people don't have to go out and create their own
orthogonality
borrowed from geometry
two lines are orthogonal if they meet at right angles - think axes on a graph
move along (or parallel to the x-axis) and theres no change to the y-axis
in computing, "orthogonality" has come to mean independence / decoupling

TWO OR MORE THINGS are orthogonal if changes in one do not affect any of the others

i.e. database code will be orthogonal to the UI. you can change the interface without affecting the database

driving stick shift is not orthogonal
helicopter controls are not orthogonal

bottom line: non-orthogonal systems are hard to maintain

Tip 13: Eliminate Effects Between Unrelated things

design components that are self-contained. this is very much the case for react components.
and for ruby methods
and for js functions
you want: independent, single, well defined components
you want: single, independent components that don't need no man

You get two major benefits if you write orthogonal systems: increased productivity and reduced risk.

ways orthogonality can be applied to your work

teams can be more efficient if each major infrastructure component gets its own subteam: database, communications interface, middleware layer, etc
non orthogonal systems lead to bickering teams
system design: should be composed of a set of cooperating modules, each of which implements functionality independent of others
inherently, i think MVC is orthogonal
the flux pattern is also orthogonal in react applications. i think? ask yourself:

if i dramatically change the requirements behind a particular function, how many modules are affected?

Toolkits and Libraries

we're talking Ruby gems, Node modules, etc
choose technologies wisely

Testing

An orthogonally designed and implemented system is easier to test. Because the interactions between the system's components are formalized and limited, more of the system testing can be performed at the individual module level. This is good news, because module level (or unit) testing is considerably easier to specify and perform than integration testing.

building unit tests is a TEST of orthogonality.
easy unit tests == orthogonal

Reversability

Nothing is more dangerous than an idea if it's the only one you have.

Writing more orthogonal code allows you to more easily reverse changess or eb and flow with the needs of the project.

Bottom line: orthognality is about reduction of interdependency among system components

Tip 14: There are no final decisions

problem: critical decisions aren't easily reversable
imagine switching a codebase to use Mongo after having tens of thousands of records in a Postgres db
HOWEVER - if you REALLY abstracted the idea of a "database" out - you should have the flexibility to make that change, should you need to
you SHOULD prepare for contingencies

instead of carving decisions in stone, think of them mroe as being written in the sand at the beach. A big wave can come along and wipe them out at any time.

this is also why i love the Adapter pattern.
for example - making a folder called "Adapters" when making external http requests in a rails app.
you might have an "geocoordinates_adapter" that has code that calls the google maps api. but because you have encapsulated this idea of geo-coding to it's own class, you're not TIED to using google maps. you can swap this out at any time. pretty dope

Tip 15: User Tracer bullets to find the target

when firing a machine gun in the dark, you either:

calculate everything and make a precise shot
or use tracel bullets.

Tracer ammunition (tracers) are bullets or cannon caliber projectiles that are built with a small pyrotechnic charge in their base. Ignited by the burning powder, the pyrotechnic composition burns very brightly, making the projectile visible to the naked eye. This enables the shooter to follow the projectile trajectory to make aiming corrections.

tracer bullet give immediate feedback and let the shooter make corrections
there are a lot of unknowns

tracer code is not disposable. you write it for keeps. it contains all the error checking, structuring, documentation, and self-checking that any piece of production code has. it simply is not fully functional

kind of like an MVP - let's you quickly iterate and get real user feedback
great part is that it gives devs a structure to work in
know that tracer bullets don't always hit the target. that's okay. just adjust and try again
tracer code is not prototyping. you will throw away the prototype and redo it later to make it "better"
this is not the case with the tracer approach
with prototyping, you might also mock functionality and make it "feel" like it's working on the front end while not actually writing the algorithm / business logic
a tracer algorithm might not be fully fleshed out but it's a skeleton that won't be thrown away
there's a different mindset

Picks

JP: react-testing-library
John: Calendly - Easily schedule meetings

NEW BOOK - The Pragmatic Programmer May 04, 2018

Show notes

The Pragmatic Programmer: From Journeyman to Master

Preface (Chapter 1)

Welcome to Iteration: a weekly podcast about programing, development and design through the lens of amazing books, chapter-by-chapter

NEW BOOK Pragmatic Programmer

by Andy Hunt and Dave Thomas

This book will help you become a better programmer

this book was written in freaking 1999! I was 7.
programming is a craft
"as a programmer, you are part listener, part advisor, part interpreter, and part dictator. you try to capture elusive requirements and find a way of expressing them so that a mere machine can do them justice. you try to document your work so that others can understand it, and you try to engineer your work so that others can build on it. What's more, you try to do all this against the relentless ticking of the project clock. you work small miracle every day"
"you shouldn't be welded to any particular technology, but have a broad enough background and experience base to allow you to choose good solutions in particular situations"

What makes a pragmatic programmer

early adopter / fast adapter
inquisitive - you ask questions
critical thinker
realistic
jack of all trades

Tips

Tip 1: Care about your craft

"We who cut mere stones must always be envisioning cathedrals."

Tip 2: Think about your work - never run on auto pilot

"great lawns need small amounts of daily care, and so do great programmers."

"1% better every day. 365% bettere every year"

kaizen - continuous small improvements

Tip 3: Provide Options, Don't make lame excuses

basically, take responsibility
when something can't be done, explain what can be done to salvage the situation

Challenge

How do you react when someone - such as a bank teller, a mechanic, or a clerk - comes to you with a lame excuse. What do you think of them and their company as a result?

hmmmmm.... really gets you thinking

Tip 4: don't leave broken windows

Software entropy - aka Broken window theory - aka software rot

This is a great metaphor:

One broken window, left unrepaired for any substantial length of time, instills in the inhabitants of the building a sense of abandonment - ... so another window gets broken. People start littering. graffiti appears.

police in NY and other major cities have cracked (no put intended) down on small stuff in order to keep out the big stuff.
systems rot quickly with one broken window. wow. this cuts me deep. haha.
don't let entropy win!!!
in the opposite case, where there are no broken windows - and its extremely pristine - you don't want to be THAT guy that makes a mess.

Tip 5: Be a catalyst for change (gradual deception and you can get what you want haha)

"The three soldiers returning home from war were hungry. When they saw the village ahead their spirits lifted—they were sure the villagers would give them a meal. But when they got there, they found the doors locked and the windows closed. After many years of war, the villagers were short of food, and hoarded what they had. Undeterred, the soldiers boiled a pot of water and carefully placed three stones into it. The amazed villagers came out to watch. "This is stone soup," the soldiers explained.

"Is that all you put in it?" asked the villagers. "Absolutely—although some say it tastes even better with a few carrots...." A villager ran off, returning in no time with a basket of carrots from his hoard. A couple of minutes later, the villagers again asked "Is that it?" "Well," said the soldiers, "a couple of potatoes give it body." Off ran another villager."

Tip 6: Remember the big picture

(don't be the frog who gets boiled gradually)

Tip 7: Make quality a requirements issue

There will always be tradeoffs. When to ship?

Great software today is often preferable to perfect software tomorrow. If you give your users something to play with early, their feedback will often lead you to a better eventual solution.

Challenges

look at some software you use. can you find evidence that companies are comfortable shipping software they know is not perfect. as a user, would you rather wait for them to iron out all of the bugs? have complex software and accept some bugs? opt for simpler software and have fewer defects?

Tip 8: Invest regularly in your knowledge portfolio

knowledge is an expiring asset
it becomes out of date as new techniques, languages, and environments are developed
JP's pick: https://www.youtube.com/watch?v=ZZUY37RQS-k - "Staying relevant as a programmer"

invest regularly
diversify
balance portfolio regularly between high risk, high reward investments
buy low and sell high
reviewed and rebalanced periodically

the same can be said for your KNOWLEDGE portfolio
Diversify: "The more technologies you are comfortable with, the better you will be able to adjust to change"

GOALS - I LOVE this section.

learn at least one new language every year. Different languages solve the same problem in different ways.
read a technical book each quarter. after you've mastered the technologies you're currently using, branch out and study some that DONT relate to your project
read non technical books
take classes
participate in local user groups (meetups)
experiment with different environments (windows, linux)
stay current
get wired (twitter - follow big players in the space)

It doesn't matter whether you ever use any of these technologies on a project, or even whether you put them on your resume. The process of learning will expand your thinking, opening you to new possibilities and new ways of doing things.

Tip 9: Critically Analyze What you read and hear

Don't get swayed by media hype. I'm looking at you create-react-app!

i was at JS.la and mentioned how create-react-app is the best configuration free react setup. someone challenged me and said it's just the best marketed

Tip 10: It's Both What you Say and the way you say it

Having the best ideas, the finest code, or the most pragmatic thinking is ultimately sterile unless you can communicate with other people. A good idea is an orphan without effective communication

kind of way we're doing this podcast!
know your audience
understand the needs and interests of your audience
think about all the people and stakeholders and domain experts you have to communicate with as a software engineer
very much, "How to win friends and influence people"

know what to Say
know your audience
choose your moment - not 4pm on a friday or when your boss is having a bad day
choose a style - know how to deliver your message
make it look good (make it pop). think about how sexy laravel docs are
involve your audience
be a listener
get back to people. ALWAYS respond back to emails. think about how it feels when people don't reespond back to you. even just a "Ill get back to you later" response is better than no response

these are great soft skills!

Our TOPPODCAST Picks

Follow Us

Stay Connected

iteration

Chapter 5 (Part 2) - Bend Or Break

Tip 40: Design Using Services

Tip 41: Always Design for Concurrency

Tip 42: Separate Views from Models

Tip 43: Use Blackboards to Coordinate Workflow

Picks

Chapter 5 - Bend Or Break

Part 1

Tip 36: Minimize Coupling Between Modules

Tip 37: Configure, Don't Integrate

Tip 38: Put Abstractions in Code, Details in Metadata

Tip 39: Analyze Workflow to Improve Concurrency

Picks

Chapter 4 - Pragmatic Paranoia

Tip 30: You Can't Write Perfect Software

Tip 31: Design with Contracts (long section alert)

Tip 32: Crash Early

Tip 33: If it can't happen, use assertions to ensure that it won't

Tip 34: Use exceptions for exceptional problems

Tip 35: Finish what you start

Picks

Tip 26: "select" isn't broken (debugging strategies)

Tip 27: Don't assume it - prove it

Tip 28: learn a text manipulation language

Tip 29: Write code that writes code

Picks

RANDOM LINKS MENTIONED! 🎉

Chapter 3 - The Basic Tools

Tip 20: Keep Knowledge in plain text

Tip 21: Use the power of command shells

Tip 22: use a single editor well

Tip 23: Always use source code control

Tip 24: Fix the problem, not the blame

Tip 25: Don't panic when debugging

Chapter 2 - A Pragmatic Approach

Tip 16: Prototype to learn

Tip 17: Program Close to the problem domain

Tip 18: Estimate to avoid surprises

Tip 19: Iterate the schedule with code

Picks

Chapter 2 - A Pragmatic Approach

Tip 11: Don't Repeat Yourself

Tip 12: Make it easy to reuse

Tip 13: Eliminate Effects Between Unrelated things

Tip 14: There are no final decisions

Tip 15: User Tracer bullets to find the target

Picks

The Pragmatic Programmer: From Journeyman to Master

Preface (Chapter 1)

NEW BOOK Pragmatic Programmer

Tip 1: Care about your craft

Tip 2: Think about your work - never run on auto pilot

Tip 3: Provide Options, Don't make lame excuses

Tip 4: don't leave broken windows

Tip 5: Be a catalyst for change (gradual deception and you can get what you want haha)

Tip 6: Remember the big picture

Tip 7: Make quality a requirements issue

Tip 8: Invest regularly in your knowledge portfolio

Tip 9: Critically Analyze What you read and hear

Tip 10: It's Both What you Say and the way you say it

Related Podcasts

1

2

3

4

5

6