Hammock Driven development - Cheat sheet

Udacity CS101 - Building a Search Engine certificate

Published Redbook

http://www.redbooks.ibm.com/abstracts/sg247548.html?Open 

Productivity Tips

Don't spend too much time on things no one sees. The full methodology one should adopt for all your work is Continuous Visible Productivity. Plan the work in terms of things other people can see and prioritise with respect to how many useful people see the result. A person who makes his boss look good is far more valuable than one who knows more technical stuff, so boss's fear of you leaving goes up without you doing anything. Any pitch for money must contain a mix of opportunities for your boss to look good with just enough fear that you might be leaving. Sound enthusiatic as everyone likes cheerful people and because it means the team is functional, which is part of business correctness.Say supportive and positive things at meetings. Demanding more money two weeks after the decisions have been made just annoys your boss.

Problem Solving techniques

1) The starting point is always the observation of anomalies/defects  in an existing system or pattern.

2) You reason on those anomalies/defects in your head, alone.

3) You come up with a possible response, alone.

4) You visualize in your head how this response would actually works. This should be practiced until you see it working smoothly from beginning to end. You do this alone.

5) Finally you set to work in order to bring this response into practice. Either alone or in a group-work.

6) Working alone: It forces you to know what you're doing, and every part of this. So you can have a deeper understanding. Plus, there's nobody to tell you what to do (For ex. "maybe if you did xx that would be better!"). So you find your own solution.

7) So when working  on your own, you gain more experience. It doesn't mean you shouldn't share it back. But you need to get some stuff done from A to Z if you want to be able to think by yourself.

Ideal Software development process

Architecture Phase:

Analysis:

• Reason: Way the Business process works needs to be be reflected in the software solution created.
• Steps: Review existing business process. Identify brand position.Identify user profiles.Create use cases.Research supporting technologies.
• Deliverable:Project Analysis report

Interface Design:

• Reason: To ensure software is intuitive, easy to use, and really does what you need it to do—well before moving into development.
• Steps: Design an interactive prototype that allows all the project's stake-holders to engage with the system in real-time.
• Deliverable: Completed User Interface design.

Usability Testing:

• Reason: To ensure the software is effective and easy to use.
• Steps: Use focus groups of target users to test the system and provide feedback until the function and usability is correct.
• Deliverable: Software Usability report

Fabrication Phase:

Software Engineering:

• Reason: You can't build a house without a blueprint.
• Steps: Create the domain mode, data schema, programming API, documentation system help.
• Deliverable:UML class and data model diagram.

Coding:

• Reason: N/A
• Steps: Develop system component, perform unit,coverage and load testing.
• Deliverables:BETA deployed to staging servers

Beta Testing:

• Reason:Find and eliminate problems before the software is launched. Well proven fact that a bug discovered in production is costs exponentially more to fix than the one found in development.
• Steps: Test all use cases and conduct acceptance testing.
• Deliverable:Deployment ready software

Production Deployment:

• Reason:N/A
• Steps:Prepare Server and deploy code to production.
• Deliverable:Production code and documentation

Job Interview preparation

These questions assume you’re being interviewed by the person who would be your manager:

1. When you’re selecting a new employee, how do you make your decision?
2. I’m very interested to learn more about your business. If you don’t mind me asking, what are some of the challenges you’ve been facing recently?
3. What kind of qualities do you look for in a Job Role (ie, Customer Service Manager) ?
4. How do you personally define success within your team?
5. Could you tell me a little bit about the best employee you ever had? In your opinion, what made them so good?

Programmer Myth

Myth: Programmers get to write code all day.

Truth: Most programmers spend a ton of time (in no particular order):

• Carefully composing e-mails to other programmers/mailing lists/non-technical folks
• Sitting in on meetings, working on mockups and DB schemas, worrying about performance implications of proposed features
• Writing bug reports and searching through bug DBs
• Supporting Production environment, scrambling to figure out why systems with numerous opaque layers are failing, digging through multi-GB log files with command line tools
• Explaining downtime to users/higher ups
• Contributing solutions to strangers’ problems
• Reading documentation/books/programming blogs/release notes/vulnerability announcements
• Searching for existing code that does what you want, maybe without knowing what that’s called
• Installing, configuring, and testing a codebase then finding it won’t work for you
• Googling error messages
• Learning source control tools, bash, GNU utilities, and Linux file permissions (and/or the Windows equivalents)
• Configuring IDEs, virtual machines, web servers, databases
• Determining which tasks to prioritize from an endless supply

Cancun

4/18: Flight - Checkin - beach - show mexican

4/19: Beach - Kayaking - show hollywood

4/20: Isla Mujers - Swim with Dolphins - http://en.wikipedia.org/wiki/Isla_Mujeres

4/21: Beach - Pool time -Market downtown

4/22: Cenote : http://en.wikipedia.org/wiki/Cenote and Chichen Itza - http://en.wikipedia.org/wiki/Chichen_Itza

My First Android Tablet NotionInk Adam

Int vs Ext

http://allendowney.com/essays/tyranny.html

Management

Reasons to avoid talking on the phone

1. Don't have time to think about the response.
2. Constantly get interrupted.
3. Cannot experience the body language.
4. Can get distracted by TV,internet etc.
5. Can get lectures instead of conversations.

Being a Producer

Create things that matter to yourself and others.

Inspire others to better themselves.

Add to conversations instead of watching others talk.

Made the world a better place in one way or another.

Knowing specific frameworks

Ten years ago, not many frameworks existed in Java, so the average number of third-party libraries included in a project were 1-5, but today, the average has grown to around 30+ like Spring, Hibernate, JUnit, Struts, Commons, TestNG, Google Guice, GWT, apache commons family et al. These frameworks change rapidly and it is impossible to know all these frameworks and it is also impossible to know some frameworks completely. The biggest detrimental this is causing is in the hiring process. Managers pass over qualified resumes looking for the names of frameworks only to land on someone less qualified who decided to put a particular framework on their resume. These folks are not necessarily technology experts so they try to bring in a candidate that has the exact blend of frameworks that the company is using. This does tend to exclude perfectly qualified candidates with real talent.

Ten years ago, having just the knowledge of a language or knowing one object-oriented language, could get you a job doing Java or C++. Now, you have to learn and have experience with every framework imaginable just to get your resume to a hiring manager. It doesn't matter what language/framework a developer knows, they are all similar. A talented developer has an interpreter and compiler in his head and thinks in pseudo-code anyway. Applying that to a language or framework is just a matter of figuring out the syntax...and that is the easy part. The talented developer just assimilates the differences.

Most jobs require a combination of 1) wisdom/sound judgment, and 2) knowledge/education/training. Of the two, the second is much easier to pick up on the job.