Josh Crews, Nashville Software School talks, November 27, 2012

nss_talk_notes.md

The mythical man month

Project estimate: 2 developers * 12 months = 24 man-months != 4 devlopers * 6 months

---

How to get paid what you're worth

Amount of value you can add to the business * your ability to communicate and negociate for a piece of that value

Amount of value = Their opportunities for profit/cost savings * your skills/effort

Your ability to communicate it

• Knowing a lot of people; and them knowing what you do
• Your ability to communitate/think in business terms
• How much they believe you will actually solve the problem vs. fail/bail
  • Client/boss's calculation: How much you might contribute / The odds you'll fail

Tips:

• Know a lot of people
• Keep a website; the website should not be ugly and should reference the search terms you want to found for
• Contribute to open source. Even if you are bad
  • You'll get better
  • Anyone can probably help with documentation
• Ask people about their business/job
• Always deliver what you say you will deliver
• Ask for testimonials

No one is in charge of communicating your skills/value in the marketplace.

What to do getting started

Keep learning; work hard, get in hours, work on teams

The morals and ethics of software development

Ethics to customers

Don't build something that

• Stores sensitive data unhashed or unecrypted or at all (password, SSN's, credit card*) [*it's not wrong to do this if PCI compliant]
• Your application promises it does before it does it (like cancel any time)
• Spies on people without their knowledge
• Spams people

Ethics to boss/client

Only commit to things you are sure you can deliver

Ethics to team members

Comment non-obvious code Give them credit where due Don't compromise team standards because of a deadline (usually testing) Don't participate is sexist/racist office behavior

If you make some ethical compromise, apologize to the appropriate party

Grow a backbone:

Your ethical principles are more important than your job.

Working on legacy projects

It can be hard, but learn to love it if possible: legacy projects run the world; and working with them well is an uncommon but in demand skill

Be honest at the start of the project about the work you think it's going to take to just improve the legacy project in order to add to it

Working effectively with legacy code

• Add some tests that just test what the code needing addressing already does
• While those tests are passing; make your change using the test to make sure you don't break it while chaning
• Write any new tests if your changes add something to functionality