Enof wisdom is in this book not only for programmg but as whole life, so need to watch new Life Wisdom I guess- no OshoStuffs n etc -isms. Vivek, I got work to do- c o d e n NOT keep returning to back-to-square-1-Oh-How-to-code. etc

exerpt from Pragmatic Programmer pdf:

euta kachra faal in 1 place. people will keep throwing there more, thinking Oh its shit place. Keep it clean - none will bother to trash-ify more. thats entropy.

–

Every now and then, you might want to emulate stone soup story.

You may be in a situation where you know exactly what needs doing and how to do it. The entire system just appears before your eyes —you know it’s right. But ask permission to tackle the whole thing and you’ll be met with delays and blank stares. People will form committees, budgets will need approval, and things will get complicated. Everyone will guard their own resources. Sometimes this is called “start-up fatigue.”

Then, It’s time to bring out the stones trick.

Work out what you can reasonably ask for. Develop it well. Once you’ve got it, show people, and let them marvel. Then say “of course, it wud be better if we added .” Pretend it’s not important. Sit back and wait for them to start asking you to add the functionality you originally wanted. People find it easier to join ongoing success. Show them a glimpse of the future and you’ll get them to rally around.

–

In Kachraa problem, people lose will to fight entropy because they perceive that no one else cares.

While frog-Which-Sits-On-SLOWLY-hitting-water just doesn’t notice the change.

Don’t be like the frog. Keep an eye on the big picture. Constantly review what’s happening around you, not just what you personally are doing.

–

GOOD ENOUGH SOFTWARE: u can discipline yourself to write software that’s good enough—good enough for your users, for future maintainers, for your own peace of mind. You’ll find that you are more productive and your users are happier. And you may well find that your programs are actually better for their shorter incubation.

If you’re working on new app, you’ll have different constraints. Marketing people will have promises to keep, the eventual end users may have made plans based on a delivery schedule, and your company will certainly have cash-flow constraints. It would be unprofessional to ignore these users’ requirements simply to add new features to the program, or to polish up the code just one more time. We’re not advocating panic: it is equally unprofessional to promise impossible time scales n to cut basic engineering corners to meet a deadline.

The scope and quality of the system you produce should be specified as part of that system’s requirements. Often you’ll be in situations where trade-offs are involved.

Surprisingly, many users would rather use software with some rough edges today than wait a year for the multimedia version. So, app initial inner circle lai prayog garna dee haal.

BUT KNOW WHEN TO STOP: In some ways, programming is like painting. painting improvise garna kehi thapera stepBack n look BigPic ta garnu parchh BUT tooMuchPerfection ko naam ma ‘throw a canvas away and start again’ jasto gari rahana hunna. All the hard work is ruined if you don’t know when to stop. If you add layer upon layer, detail over detail, painting becomes lost in the paint.

Don’t spoil a perfectly good program by overembellist. Move on, and let your code stand in its own right for a while. It may not be perfect. Don’t worry: it could never be perfect.

–

Invest in KNOWLEDGE just like invest in stocks by:

1. Serious investors invest regularly—as a habit.
2. Diversification is the key to long-term success- As a baseline, you need to know the ins and outs of particular technology you are working with currently. But don’t stop there. The face of computing changes rapidly—hot technology today may well be close to useless (or at least not in demand) tomorrow. The more technologies you are comfortable with, the better u will be able to adjust to change.
3. Smart investors balance their portfolios between conservative (je legacy wala which gives u breadButter) and high-risk, high-reward investments.
4. try to catch up new tech like finding about btc in 2012.
5. Portfolios should be reviewed and rebalanced periodically.

TakeClasses, ParticipateInLocalUserGroups, StayCURRENT, AskGURUs

Just because a Web search engine lists a hit first doesn’t mean that it’s the best match; content provider can pay to get top billing. Just because a bookstore features a book prominently doesn’t mean it’s a good book, or even popular; they may have been paid to place it there.

–

As programmer, you are

-part listener

-part advisor

-part interpreter

-part dictator.

You try to capture elusive (difficult to find, catch, achieve) requirements

& find a way of expressing them so that mere machine can do justice. U have to be able to make machine do so.

-You try to document your work so that others can understand it.

-You try to engineer your work so that others can build on it, that too against ticking of time, you work small miracles everyday.

– Not necessary that 1 by-the-book thing as best solution in ur situation. Situation dictates it. You adjust your approach to suit current circumstances. You judge relative importance of all factors affecting project n use ur experience to produce appropriate soln.

You should have broad enough background n experience base to allow u to choose good soln in case that u are now facing.

Your background stems from understanding of basic principles of computer science N your experience comes from wider range of practical subjects. THEORY n PRACTICE combine u to make strong.

– Each developer is unique, w individual strengths n weaknessses, preference n dislikes.

Over time, each will craft his/her own personal environment. That environment will reflect his/ her individuality of solving problems, tools/ approach he uses, just as forcefully as his/her hobbies.

So, way/approach of solving problem is not one - by-the-book kind. However, pragmatism can be best summarized as below traits:

-Early adopter/ fast adopter: U have instinct for tech n techniques, n you love trying things out. When given sthg new, u can grasp it quickly n integrate it w rest of your knowledge.

-Inquisitive (having/ showing interest in learning things after being convinced, ok there’s pt. learningn it): U tend to ask questions- ‘How did u do that’ ‘Did you have problems w that library’ ‘What;s this llm that I’ve been hearing about’ ‘How are symbolic links implemented’ etc

-Critical Thinker: U rarely take things for granted without getting the facts. I have talked about this Not-Impulsive-But-paying-attention-to-details in ‘Cavemen’s dilemma’ blogpost

-Realistic n resilient: U try to understand udnerlying nature of each problem. This realism orientation gives u good feel of how difficult things are, n how long things will take. Understanding for urself that a process would be difficult gives u stamina to keep at it.

-Jack of all trades, master at one

–

Care ur craft, think about ur work

–

In order to be pragmatic programmer, u will feel challenged to think about what u’re doing while doing it. This isnt one time audit of current practices - it’ss ongoing critical appraisal of every decision u make, everyday n in every development.

Never run on auto-pilot Constantly be thinking, critiquing your work in real time.

– Individual pragmatists, each one in even large teams. One who cuts mere stones must always be envisioning cathedrals.

– Improvement is a continuous ongoing process.

– Producing formatted documents from the comments and declarations in source code is fairly straightforward, but first we have to ensure that we actually have comments in the code.

In code, comments should discuss O N L Y why something is done, its purpose and its goal. The code already shows how it is done, so commenting on this is redundant and is a violation of the DRY principle.

Commenting source code gives you the perfect opportunity to document those elusive bits of a project that can’t be documented anywhere else: engineering trade-offs, why decisions were made, what other alternatives were discarded, and so on.

We like to see a simple module-level header comment, comments for significant data and type declarations, and a brief per-class and per-method header, describing how the function is used and anything that it does that is not obvious.

Variable names, of course, should be well chosen and meaningful. foo, for instance, is meaningless, as is doit or manager or stuff. Even Worse is Misleading names, DONT.