Keeping

stakeholders

informed

Prioritize

Demos

DesignEsti

mate

Unlearn

Integrate

Data modelling

Learn

UX

Manage Time

Quick TAT to

emails

Black box

Reviews

Code comments Estimate

Prototyping

Prioritize

Requirements

Reviews

Refactoring

Kick offWhite box

Implementation

Build

Testing

Coding

Deploy

vipinprogrammingthe

programmer}{

vipin kumar

software architect

» Pragmatic/Professional Programmer» Learn / Unlearn» Refactoring» Code Comments» Eisenhower matrix

take Responsibility

» responsible for their own career» doctors and lawyers

» responsible for the code they write» expect QA to find bugs

» do not make a mess» surgeon don’t come back and fix it later

» responsibility for the output of the team» help one another, teach/learn from one another

» don’t tolerate big bug lists

» write code as if you had to support it for the rest of your life

» care for your code» avoid hacks» write discoverable/maintainable code

software Entropy and Change

» don’t live with broken windows

the stone soup

learn / unlearn

» stay marketable – else become a dinosaur» take responsibility for your own education

» read books / magazines – twitter feeds, websites, subscribe to blogs

» have a mentor / virtual mentor

» know your frameworks / libraries» teach or speak to someone» learn a new language every year – new tool

» join meet ups» learn the domain to solve the business problems

» read code

» open source» no free lunch

» be the Neo of the Matrix

refactoring

act with prudence

» doing it right / doing it quick

act with prudence

» technical Debt» keep track of technical debt» pay off at the earliest

before you refactor

» take stock of existing code base

before you refactor

» avoid rewriting everything

before you refactor

» Make incremental changes

before you refactor

» after each iteration, make sure existing plans pass

before you refactor

» new technology is insufficient reason

» leave the campground cleaner than you found it» little better than what you checked it out

» improve code by removing it – less is more» keep the build clean - warnings» Simple - extra anything should be purged immediately

» think of every line of code as a message for someone in the future

code comments

A theoretical purist who believes everything he reads

A battle-hardened veteran from the old school—a "real" programmer

A young, confident, hot-shot computer jock

A senior programmer tired of big promises, just looking for a few practices that work

effective comments

» if it is hard to write, it should be hard to read» code should explain itself to the next programmer» know when not to write a comment» explain what the code is supposed to accomplish» comments that parrot the code offer nothing extra» comments should be treated as code – add value» code reviews – help identify if a comment is needed

coding style

Routines

» Does each routine's name describe exactly what the routine does?

» Does each routine perform one well-defined task?

» Is each routine's interface obvious and clear?

Data Names

» Are variables used only for the purpose for which they're named?

» Are loop counters given more informative names than i, j, and k?

» Are well-named enumerated types used instead boolean variables?

» Do naming conventions distinguish among type names, named constants, local variables, class variables, and global variables?

eisenhower matrix

the problem

» infinite number of things to do» finite number of hours» want to feel good about what I am NOT

doing

break up your TODO list

two questions

» is this important?» is this urgent?

What’s important?

What personally you need to take care of

What’s urgent?

What needs to be taken care of SOON

Urgent Not Urgent

Important

NotImportant

Urgent Not Urgent

Important

NotImportant

Do First

Urgent Not Urgent

Important

NotImportant

Schedule

Urgent Not Urgent

Important

NotImportant

Delegate

Urgent Not Urgent

Important

NotImportant

Don’t Do