1. Invalidity 2. We Sell Value
3. Technical Interviews
4. Recent Studies
5. Needles and Haystacks
6. The Importance of the Dev
7. Programmers Born or Made?
8. Fair, Good, Great Programmers
9. Real Life Peer Review
10. Testing Needed
11. Smart Trolls
12. Devs who Become Managers
13. The Necessity of Peer Review
14. Great, Average, Bad Programmers
15. What to Focus On
16. Working Remote
17. Typical Peer Review
18. Support vs. Junior vs. Senior Programmers
19. Incapable Programmers
20. The Best Boss
21. Bad Things Can Happen
22. Production Bugs Shouldn't Happen
23. Why Bad I.T. Managers?
24. Change One Thing at a Time
25. I Don't Know What I'm Doing
26. Instability or Resolve?
27. Unlearning Bad Habits
28. How to Prevent Bugs
29. Best Way to Software Quality?
30. Pioneer vs. Guinea Pig
31. The Best Way to Get a Promotion
32. The Right Person for the Job
33. Groking = Buzzing
34. Wisdom Accumulation vs. Expenditure
35. Perfection Can be the Enemy
36. Sometimes the Less People, the Better
37. Why Drives Great Software
38. Giving is a Key Differentiator
39. Customer Success > Our Own Success
40. What Did I Miss?
41. Smart vs. Accomplished
42. "About Customers" > "About Myself"
43. Software Suckiness
44. Coming Up to Speed Should Be Quick
45. The Worst Word: Can't
46. Consequences > Rewards or Punishments
47. My Old Code Always Surprises Me
48. Gaming Resumes
49. Religious Preference 50. What Do You Hack?
51. You Can't Be Half a Programmer
52. People are More Important than Process
53. I Hate Battle Hack
54. Better Database Design = Less Code Needed
55. You Need More Programmers than Managers
56. The Past, Present, and Future of Learning
57. Who Writes the Code Standards? 58. Your Org Chart is Upside Down
59. You Become Senior Before You're Called Senior
60. The Underappreciation of Domain Knowledge
61. Managers Must Be Humble
62. Programmers Do Get Better with Age
63. Simplifying + Organizing = Understanding
64. Another Reason I Hate Deadlines
65. Testing Never Disproves Bugs
66. The Downside of Long-Time Employees
67. Ability Trumps Certification
68. Most Problems are Multiple
69. Regression Testing Separates Excellent from OK
70. I.T. Decisions Should be Made by Programmers
71. Touch at Your Own Risk
72. Teach Them How to Use You
73. What Ever Happened to Training?
74. Minimum Viable Debugger
75. All I Did Was
76. Always Tell the Truth
77. Isolate! Isolate! Isolate!
78. Philosophy by Luck
79. Why Have Standards?
80. Incompetent People Increase Everyone Else's Work
81. The Real Star is Your Customer's Customer
82. Hack Your Customer's Problems as Much as Your Own Code
83. Conventional Wisdom Leads to Conventional Results
84. Resources Required to Get Work Done
85. Combining 2 Different Jobs Creates a 3rd Problem
86. Meeting != Building
87. Just Write the Code
88. My Software Building Metaphor
89. Preventing Bugs > Fixing Bugs
90. Bad, Better, Best Ways to Determine What
91. Primitive Debugging is Usually Enough
92. To a Dev, "Expensive" Means Time, not Money
93. 20 Year's Experience > 1 Year's Experience 20 Times
94. Sometimes the Dumb Questions are the Best
95. Your Releases Suck
96. How Am I Making This Too Hard?
97. The Endless Questions
98. Turn it on Anyway
99. I Didn't Know That I Couldn't Do It, So I Did It.
100. Customers Rarely Understand What It'll Take
101. 3 Kinds of Trade-Offs
102. Something Today > Perfection Tomorrow
103. Expertise vs. Imagination
104. What to Understand
Chapter 2 - Habits
105. I Hate Deadlines
107. Deep in Thought
109. Planning for Tomorrow
110. Mindset Changes
111. Useful vs. Useless Knowledge
112. Portrait Mode Monitor
113. Lines of Code Written 114. Appropriate Breaking Points
115. Preparing the Night Before
116. 3 Work Modes
117. Digital Training Wheels
118. Expectations vs. Reality
119. The Worst vs. the Second Worst
120. Preparing the Night Before
121. End Procrastination
122. Who to Code For
123. Fear vs. Everything Else
124. In the Zone
125. Focus and Procrastination
126. Thinking vs. Building
127. Preparation is 90% of the Battle
128. Work Flow's 2 Most Important Questions 129. Accomplishment Before Distraction
130. The Best Way to Learn is Building Something
131. How Building Something Changes Your Brain
132. Understanding Your Role
133. Planning and Review is as Important as Building
134. You Can't Learn Everything
135. Sometimes, the Less Tools, the Better
136. Just Slow Down a Little
137. Junk Food for Programming
138. Certainty Usually Leads to Changing My Mind
139. Gaining Control Over my Habits
140. A Platform is the General Case of an App
141. You Need Both Coding and Not Coding
142. The Dilemma of a Natural Optimizer
143. Most Real Work is Done by One Person
144. Valuing Time and Cell Phones Are Opposites
145. All or Nothing at All
146. I Can't Help Putting Off Unpleasant Tasks
147. Sometimes Less is Harder than More
148. Time of Day Does Matter
149. Showing Up is Half the Battle 150. Leave Something Unfinished Every Day
151. Mornings Are Mine 152. For Some of Us, Time > Money
153. Know Which Mode You're In
154. The Power of Now
155. Different Modes Accomplish the Same Thing
156. Do Not Interrupt If I am Busy
157. My #1 Productivity Hack
158. Sometimes It's Not a Technical Problem
159. One Move Ahead is Enough
160. Just Build Something
161. Not at My Computer is the Most Important Part of My Setup
162. Smart Today is Often Stupid Tomorrow
163. How am I Making This Too Hard?
164. Something is Never Enough but It's Still Something
165. Code Drunk. Refactor Sober.
166. Prototyping is Like Squeezing a Nerf Ball 167. Compulsion
Chapter 3 - Code
168. Checking the Index
169. Code in a Diaper
170. Proper Naming 171. Pseudocode
172. Premature Optimization
173. Long Case Statements
174. Lowest Common Denominators 175. Optimism vs. Pessimism 176. When to Decide 177. My Big 3 Programming Guidelines
178. How to Build a Platform
179. Totally Redeem Yourself!
180. Bug Fixes
181. Going Meta
182. Poor Variable Naming
184. Automated Code Review
185. Client vs. Server
186. Build Better, Test Less
188. We're Already Doing That
189. The Variable "flag"
190. The Team Player Programmer
191. Early Exits
192. Best Judge of Programming Skill?
193. My Dev Stack Hasn't Changed
194. Optimization Blessing vs. Curse 195. Good vs. Bad Programmers
196. Swimming in a Parka
197. Time vs. Money
198. The Negative Side of Frameworks
199. Some Bug Fixes Deserve a Drink
200. Prototype vs. Industrial Strength
201. Wrapping My Head Around Nesting
202. When Will We Automate Software Building?
203. The Ebb and Flow of Building Software
204. Enforcing Code Review Errors
205. Exact Variable Naming
206. Pessimistic vs. Optimistic Locking
207. The Real Purpose of Frameworks
208. Throwing Code Away
209. Clever Can Backfire 210. Minimum Universal Code Standards
211. A Program Should Read Like a Story
212. Variable Naming is Half the Battle
213. Half of Figuring Out is Variable Naming
214. DRY = Don't Repeat Yourself
215. Always Keep the Next Programmer in Mind 216. Who Are You Really Coding For?
217. Data Outranks Code
218. Cleverness Leads to Leverage Which Could Lead Anywhere
219. The Right Times for Early Optimization
220. When Clever Code Becomes Technical Debt
221. Shut Up and Build Something
222. How to Punish Lengthy "if" Statement Generators
223. A Program Should Read Like a Story
224. No Tool Handles Everything
225. Programs Should Tell Stories
226. Variable Naming is More Important than Appearance
227. Early Exits are Lazy
228. Code Running Wrong is Worse than Code Not Running
229. Indenting is Illogical
230. What Were They Thinking?
231. Optimize Human Time Over Machine Time
232. Spaghetti Code Happens
233. When to Apply a Principal or Not
234. Today's Early Exits are Tomorrow's Technical Debt
235. Getting Started Can Be Easier
236. Name Your Variables and Functions Meaningfully
237. You Should Be Able to See the Whole if Statement
238. It's Probably Something You Did
239. Always Code Correctly
240. Cleverness Often Leads to Confusion
241. Sometimes Even the Best Devs Suck
242. Comment Sense
243. It's Too Hard to Read Code with Poorly Named Variables
244. The Right Tool for the Right Job
245. Your Tool Box Doesn't Have to Hold Much
246. The Real Measure of Clear Production Software
247. Lines of Code is Often a Meaningless Metric
248. Proper Variable Naming Shrinks the Problem
249. The Next Programmer is as Important as the Current Computer
250. The Gap Between the Early Exit and the Return
251. Optimized Code vs. Structured Data
252. You Only Notice It If It's Wrong
253. Technical Debt
254. Looking Back at my Old Code
255. Simplify Your User Interface!
256. A Platform is Much More Complex than an App
257. With Code, Less Can Be More
258. Sometimes More Problems Can Mean Progress
259. Step Back to Step Forward
260. When is Just as Important as What or How
261. The Smallest Changes Can Cause the Biggest Problems
262. Better Words in Function Names
263. Auto-Generated Alphanumeric IDs
264. Good Code Forever > Good Code Today
265. Should > Must
266. 2 Most Important Things for Commercial Software
267. The Better the Code, the Less Need for Comments
268. Being On Time Doesn't Count if it Sucks
269. The VAN Method of Naming Functions
270. Wanna Start Faster or Finish Faster?
271. The Users Love Him but the Programmers Clean Up After Him
272. Long if Statements are Time Bombs
273. Bad Code + Comments = Worse Code
274. Quick and Dirty is One or the Other 275. Name Your Variables to Stop Questions
276. Write for the Next Programmer
277. Jumping to the Wrong Conclusion
278. Sometimes 95% > 100%
279. The Real Definition of "Agile"
280. Understanding it a Year Later
Chapter 4 - Lifestyle
282. Where's Their Visit?
283. Software Craftsman
284. Work vs. Joy
285. Building vs. Everything Else
286. Language Choice
287. Generational Assets
289. Do vs. Say vs. Write
290. Task Preference 291. Old Programmers 292. Imposter Syndrome
293. Co-working Spaces
294. Children Becoming Programmers
295. Real Competitions
296. Imposter Syndrome as an Antidote
297. Not Doing Harder than Doing
298. Programmers Help Others
299. Why Procrastination?
300. Pleasure of Work
301. Anticipating Something Good
302. Programmers Understand Building
303. Staying Put in Good Jobs
304. IDE du Jour
305. Do It Anyway
306. Criminal Negligence
307. Work vs. Games
308. Work vs. Living
309. Fun vs. Easy
310. Fixing Bugs
311. The Value of Backspace
312. High Focus
313. Why High Achievers Quit
314. Sitting All Day Long
315. Quality vs. Quantity in Programming
316. Twitter vs. Work
317. Programmer vs. Posegrammer
318. Deploying Sober vs. Drunk
319. Down-voted vs. Ignored
320. Needing Less Tools
321. What Defines Us
322. 100 Years from Now
323. Most Important for CS Student 324. Clever vs. Understanding
325. Talking about Procrastination
326. Preparation + Opportunity = Luck
327. Yikes! vs. Wow!
328. 45 Minutes Chunks are Worthless
329. The Crap of Others
330. The Real Bad Words
331. Writing Joy
332. Cool vs. Important
333. Work vs. Joy
334. So I Code
335. Today's Cleverness = Tomorrow's Confusion
336. Elegance != Mystery
337. The Entrepreneurial Book Paradox
338. Fixing Bugs vs. Changing Diapers
339. Not Afraid of Satan
340. Success is Critical
341. Learning by Dumpster Diving
342. Delivering vs. Complaining
343. Fizzbuzz Debate
344. Motivation to Code
345. Success and Failure
346. Happy Dance
347. A Programmer is Like a Corvette
348. How Things Have Changed
349. Even Snowflakes Must Work to Get Something Done
350. The Value of Negative Feedback
351. Don't Touch My Masterpiece!
352. Time Measures by Business Type
353. Ugly Unmaintainable Code
354. Building is Not a Zero Sum Game
355. My Bike Changes My Thinking
356. If I Could Only Go Back
357. Virgin Code
358. Health for Time vs. Energy
359. Writing Software vs. Writing a Book
360. Support Programming in an Emergency Room
361. Programmer's Tools Include Peace and Quiet
362. Rewrite or Not?
363. Fixing Others' Crappy Code
364. Learning What Not to Do
365. Competition != Achievement
366. Pizza Makes Bug Fixing More Palatable
367. Emotion is Fuel
368. Programmer + Junkfood = Code
369. Juniors Who Judge Rarely Become Senior
370. How Software is Like Comedy
371. Almost Funny Code Comments
372. The Maintenance Programming Mess
373. Which Beer Did This to Me?
375. Why More Maintenance than Development?
376. You Can Program Forever
377. Sometimes, Determination is the Critical Differentiator
378. Programming Takes a Lot of Time!
379. Code with Empathy
380. Every Minute of Inspiration is Followed by an Hour of Grunt Work
381. It's Easier to Do It Right than Wrong
382. The Good Path is Often Tortured
383. Bewilderment Often Leads to Wonder
384. The Technical Debt Treadmill
385. Quiet Desperation
386. Cube Farm Noise vs. Signal
387. The Bug Needle and Haystack
388. Cube Farm == Work Prevention Area
389. Come Back Tomorrow
390. Coding is a Small Part of a Programmer's Time
391. I Should Be Having a Ball with This
392. Achieving Eases Burning Out
393. You Can't Get Wet from the Word "Water"
394. Osscilation is the Solution
Chapter 5 - Software
395. Look at the Source Code 396. What Makes a Senior Dev?
397. Programmer Bookshelves
398. Software Class
399. Object Orientation
400. How to Slow Down
401. What's Most Important?
402. Knowing Your Apps
403. Why Get an MBA?
404. Uncommon Sense
405. Breakthrough Software
406. Bad, Better, Best Action
407. Do It
408. Batch Processing
409. Conformity 410. Some Things Never Change
411. User as Admin
412. Good, Better, Best Knowledge
414. Time Needed
415. Imagination vs. Determination
416. Framework Weight
417. Satisfied with Results?
418. Ones and Zeros vs. People
419. Sources of Inspiration
420. 1X vs. 10X vs. 100X
421. Platforms vs. Apps
422. Deep Diving
423. Solutions Looking for Problems
424. Supporting Data
425. The Software vs. Everything Else
426. Lost Opportunity
427. Play vs. Work
428. Wild Goose Chase 429. What vs. Why vs. How
430. 1X vs 10X Programmer
431. Appearance vs. Work
432. Commitment vs. Involvement
433. Junior vs. Average vs. Good vs. Excellent
434. Interviewing the Interviewer
435. Just Right Data 436. System Design Fundamentals
437. Right vs. Fast vs. Cheap
438. Too Many Devs in the Kitchen
439. The Speed Things Happen
441. No Class or Manual Needed
443. Cycle Time ROI
444. Money Beliefs
445. Who Should Kick Butt?
446. What Better Way to Fix It?
448. What You Do for Others
449. Best Thing About Getting Older?
450. Enterprise Workarounds
451. Who are we Programming For?
452. 3 Things to Never Say
453. Sources of my Difficulties
454. Getting Deeper
455. Fit vs. Quality
456. Document What Goes On Under the Hood
457. What to Believe from a User
458. Fundamentals Came Before the Web
459. Dialogue Boxes from Hell
460. Sometimes the People Part is the Toughest
461. Legacy Software, Good or Bad?
462. Software Quality vs. Speed
463. What if Software Could Write Itself? 464. With Automation, Sometimes More is Less
465. Business Intelligence is Cover for Poor Design
466. It Will Have to Scale 467. Optimistic vs. Pessimistic Database Locking
468. Email = Meetings with 1 Person
469. Data vs. PROCESS
470. It's Easier to Combine than to Separate
471. Buy or Build?
472. For Code, Resiliency is a Level Above Functionality
473. Why are Databases So Poorly Designed?
474. Different Data, Same Processing
475. Handle Bad User Input
476. Clever Architecture > Clever Code
477. Building on the Shoulders of Flawed Giants
478. Bugs are not Always Software Defects
479. Embrace and Protect Good Tech
480. An App Can Grow Up into a Platform
481. Service Businesses vs. Product Businesses
482. 4 Types of Coworkers
483. The Better the Software, the Less Customer Service Needed
484. Never Delete. Just Archive.
485. Half the Battle is Knowing What to Build
486. Who is Your Technology Actually Enabling?
487. A Platform = An App Squared
488. The Code is the Only Real Truth
489. The Technical Debt Cow is Already Out of the Barn
490. Software Can Be Your Best Coworker
491. Learn the Base Language Before the Framework
492. Proper Data Structure Simplifies the Code Needed
493. Good Geeks vs. Bad Geeks
494. Sometimes More Infrastructure is Less
495. Optimistic vs. Pessimistic Locking
496. Know When to Reinvent the Wheel
497. When Not to Reinvent the Wheel
498. Fast, Cheap, Good: Take All 3
499. Tense Is Important
Chapter 6 - Building
501. Agile Delivers 502. Written Requirements 503. 10x Project Life Cycle
504. Creating vs. Criticizing
505. Story Descriptions
506. Beer vs. Thirst
507. The Agile Diner
508. Cause vs. Effect
509. Masking the Mess 510. Move or Fix?
512. So What?
513. Critical Path vs. Weak Link
514. Analysis vs. Design
515. Self-explanatory Specs
516. No More Meetings
517. Promise vs. Due Date
518. Plan or Not?
519. Questions vs. Answers
520. Which Option Do You Prefer?
521. Theory vs. Experience
522. Agile vs. Systems Analysis
523. Three Simple Steps
524. How vs. What
525. Hours Required on Specs
526. What to Build?
528. How to Define Success
530. Precision in Promises
531. Certification vs. Capability
532. Testing Specs
533. Send Me the Reqs
534. When UAT = Analysis
535. Gold vs. Platinum
536. Language Choice is Often Unimportant
537. Ideal Specs Size?
538. What's on Your White Board?
539. Waterfall's 1000X Problem
540. Why + What + How = Estimate
541. Endless Negotiating
542. All it Takes to Build Something
543. 11th Hour vs. 13th Hour
544. The Better the App, the Less Need for Excel
545. Precision is Half the Battle
546. Concepts are Simple. Execution is Complex. 547. Sometimes, Thinking = Building X 10
548. How to Measure Programmer Cleverness
549. I Prefer Small Projects by Myself
550. Seeing It Before It's There
551. A Process Shouldn't Replace Thinking
552. Abraham Lincoln Could Have Been a Programmer
553. Designing from the Inside Out
554. Better Planning and Coding Reduces Testing Need
555. We Need More Precision Up Front, not Less
556. Testing Addresses Failures Earlier in the Lifecycle 557. Binary Completeness
558. I Still Suck at Estimating
559. No Change is Minor
560. It's Not How Fast You Start, But How Soon You Finish
561. I Hate Deadlines
562. The Beauty of Front Loading a Project
563. Verbal Specs Aren't
564. Tech Specs Must Include Test Instructions
565. Most Help Tickets Are Poorly Written
566. I Learn More From Failure
567. Knowing When to Quit is Critical
568. Understand Before Estimating
569. Write It Down!
570. Time Spent Up Front Saves Time Later 571. Slow Down So That Others Can Learn
572. Determine Estimates, Don't Negotiate Them
573. Almost Everyone Sucks at Analysis
574. You Still Need Requirements for Agile
575. Precise Communication Jumpstarts Everything
576. Good Enough Today > Perfect Tomorrow
577. For Me, Code is Easier than People 578. Programmers Need More Time With Users
579. The User, not IT, Should Own The Project
580. Certification != Accomplishment
581. Ask the Right Questions 582. Agile Does Not Replace Requirements Definition
583. Most Project Plans Suck
584. What, Then How, Then Do
585. Verbal Business Requirements Aren't
586. Start with the answer and then work back.
587. Let Us Work on It!
588. Analysis Precedes Everything Else
589. Some Customers Just Need to be Fired
590. Geometric Time Savings
591. Don't Forget the Grunt Work
592. I Overestimate How Much I Underestimate
593. Simplify and Add Back Later
594. The Cost of Writing Specs < The Cost of Rework
595. Offshore Development Can Be Wonderful if Done Correctly 596. ROI Beyond 6 Months is Often Worthless
597. The Project Sweet Spot
598. Vagueness Correlates Highly with Juniorness
599. The Product is the Software, not the Spec
600. Asymptote = Never
601. I Still Hate Deadlines
602. Define the Big Fat What Before Writing Code
603. The Typical Song and Dance
604. Big Fix vs. Enhancement
605. Ask Lots of Questions for Better Requirements
606. Project Managers Must Understand
607. Blame the Programmer
608. Start with the Answer, Then Work Back
609. Deadlines Force Compromises
610. Unfinished Software
611. What's a Bug?
612. Dad was Right All Along
Chapter 7 - Process
614. They're All Bugs
615. Tool Overhead 616. No One is Responsible
617. Struggling with Tools
618. Standup Meetings
619. More vs. Less
620. Strengths vs. Weaknesses
621. Efficiency vs. Overhead
622. Agile, Good and Bad
623. People and PROCESS
624. Programming vs. Not Programming
625. Agile and Technical Debt
629. LinkedIn B.S.
630. Good and Bad Workmates
631. Who Owns the Program?
632. Bad Meetings
633. Scheduling Paradox
634. The Wrong Thing Better 635. Metrics
636. End-to-End Testing
637. Home like Work
638. Illogical Logic
639. Unresponsive Bosses
640. Metrics vs. Work
641. Confidence in Your Process
642. Learning Illogic
643. Bad Management Decisions
644. Meetings, Meetings, Meetings
645. Reasoning Behind the Process
646. Time to Move to Production
647. Nervous Move to Production
648. Dartboard Project Managers
649. Drug Testing
650. Bugs, Unacceptable or Unavoidable?
651. Where to Get Creative
652. Customers Problems vs. Our Own
653. Ratio of Time Programming
654. When Do We Code?
655. Public vs. Private Companies
656. Regression Testing 657. Communication Problems
658. Enterprise vs. Startup vs. Game Changer
659. PTO as Tolerance
660. Metaphor for High Achievers
661. 2 Weeks' Notice
662. LIFO vs. FISH vs. WTF
663. 10X vs. .1X
664. Programming Overhead
665. Decline that Meeting?
666. Timelines Too Long
667. How I Estimate
668. Who Supports Deployed Code?
669. Meetings vs. Progress
670. Stand Ups Become Sit Downs
671. The Reasons Behind the Madness
672. Process as Molasses
673. Supporting It Forever
675. Recruited for Your Own Job
676. Don't Do That
677. You Must Write to Get Something Done
678. Too Many Devs in the Kitchen
679. Optimal Meeting Scheduling
680. Work vs. The Appearance of Work
682. Agile Barbers
683. Nothing Done without a Ticket
684. No Meetings for 3 Weeks 685. Better Communication through Writing
686. Good Writing Makes Meetings Unnecessary
687. Peer Review of "e=mc2"
688. Strategy vs. Urgency
690. The Punishment for Tardiness
691. Code Review Retribution
692. Who Owns It?
693. We Must Spend More Time Building
694. How to Work a Problem
695. Software Development != Industrial Engineering
696. So Many Tools Suck
697. Awkward Peer Review Decisions
698. Horrible Process or Well-Leveraged Software?
699. Time Sheets Suck
700. Need it Faster? Call it a Bug Fix
701. Meetings Beget More Meetings
702. All Human Dependent Processes Eventually Fail
703. Talking != Meeting
704. Lack of Precision Can Kill
705. Changing Passwords Regularly is Illogical
706. Triage Must be Accurate
707. Salespeople Should Understand Everything They're Selling
708. Process Must Handle Urgency
709. Ask Before You Need It
710. Don't Provide Negative Value
711. Fix the Root Cause and You Won't Need the Metric
712. How Urgent?
713. Peer Review is an Investment, not an Expense
714. No Standards Are Better than Bad Standards
715. The Bad Legacy Code Just Keeps Growing
716. Meetings, Time Sheets, or Work. Choose.
717. Hope They Don't Quit
718. Which Comes First, UAT or Code Review?
719. If Home Was Like Work 720. QA Can Fail in Any Link in the Chain
721. Verbal Specs Aren't
Chapter 8 - Business
722. Building vs. Problems
723. Send Them Back
724. Beauty Pageants
725. When the Boss Brags 726. Time or Something Else?
727. Good, Better, Best Devs
728. Quality vs. Quantity Reviews
729. Who Interrupts?
730. Salary Information
731. Double Negative Value
732. Continuous Improvement 733. Simplification
734. Acquisition Hell
735. How to Avoid Bugs
736. Publicizing Successes
737. Managing High Achievers
738. Bad IT Management
739. Manager vs. Programmer
740. Business Intelligence
741. The Brutal Truth
743. IT's Biggest Problem 744. IT's Second Biggest Problem
745. Project Participation Percentages
746. Someone Has to Do Something 747. Mission Statement
748. Regression Testing
749. Competent Technology Managers
750. Managing Programmers
751. Customer Service
753. Who's Most Important?
754. Email Replies
755. The Two Most Important Things
756. Tools Need Standards Too
757. Good Bosses
758. Simplest Ecommerce
759. Quick and Dirty
760. Insecurity as an Excuse
761. Managing Programmers
762. Accomplishment vs. Judgement
763. Bad Comparison
764. Loyalty in Companies
766. Recalling Passwords
767. Stopping Caring
768. Both Technology and Business
769. Do Real Work
770. Argument for Bootstrapping
771. Marketing vs. Content
772. Nasty Bugs
773. Business Plan Competitions
774. Working but Not Working 775. Why You Don't Get Honest Feedback
776. Good, Better, Best Manager
777. Failing to Do Right can be Worse than Doing Wrong
778. Conventional Wisdom is Often Wrong
779. I Don't Know
780. Crappy Programmers Make Crappy Managers
781. Good at Hard vs. Bad at Easy
782. Meetings are the Opposite of Work
783. Which Criticism Matters?
784. Impress Customers Before Investors
785. So Many Good Things Don't Mix with SOX
786. Satisfy Customers!
787. Everyone is in the Information Business
788. SOX Sucks
789. I.T. Must be a Trusted Partner
790. Due Diligence for Purchased Software
791. Avoiding Difficulty > Handling Difficulty
792. The Most Important Programmer Metric
793. It's Almost Never the Money
794. The Source Better Match the Object
Chapter 9 - Management
795. Bosses Drinking 796. Selfishness
797. Enterprise IT Drudgery
798. Happiness from my Boss
799. How Smart to Be?
800. Not a Team Player 801. Less Emotional
802. I.T.'s Biggest Problem
803. Dumb Managers
804. Counting vs. Having
805. Not a Team Player
806. Donut Bait
807. Best Way to a Bigger Paycheck
808. No Need to Google
809. Junior vs. Average vs. Senior
810. Good vs. Bad Companies
811. Defaulting to the Worse Choice
812. Bad, Better, Best Management
813. Bad vs. Good Bosses
814. Excellent vs. OK
815. Where High Achievers Thrive
816. Source of Problems
817. IT Managers as Children 818. Underestimating the Value of Programmers
819. You Think Like a Manager
820. Worker Input
821. Development vs. Bugs
822. Senior vs. Regular vs. Junior vs. Manager
823. Meeting or Write Software
824. Ethics are Binary
825. Acting as if You Knew
826. IT is a Factory
827. Never Having Done It
828. You Need Vision
829. The Time Warp
830. Happiness vs. Blame
831. Brilliant IT Management
832. Appropriate Rewards
833. Acting Like Parents
834. 2 Wrongs != 1 Right
835. Must vs. Should
836. The Perceived Value of Programmers
837. Better than Everyone Else
838. Direct Labor vs. Overhead 839. Every Product Includes Ones and Zeros
840. Programmers vs. Pro Athletes
841. Managers Playing with Phones
842. Inbox Zero
843. Cause vs. Effect
844. Naive vs. Blind vs. Wise Executive
845. Partners with a Common Goal
846. Where to Search
847. When You Know It's Fruitless
848. Living Breathing Code Standards
849. Religious Objections
850. ROI Theory vs. Practice
851. Wasting Oxygen
852. Process vs. Work Prevention
853. Deliverable Quality vs. Quantity
854. Not a Work Prevention Team Player
855. Team Player vs. Lone Ranger
856. Less Time for Bugs
857. What are Best Practices?
858. Traditional vs. Start Up vs. Enterprise
859. Jumping to Conclusions is a Big Weakness
860. How My Energy Works
861. Who Needs Who More?
862. Having More to Count
863. Programmers Produce Value, not Minutes
864. Most Bosses Don't Appreciate Workers
865. Why Don't Managers Listen to Those Who Know?
866. Addres the Cause, Not the Effect
867. Our Fearless Leader is Neither
868. Managers Should Listen More Than Talk
869. Yes is Better Than No
870. Keep It Simple Stupid!
871. Survival of the Prettiest
872. Politics != Business
873. Gut Feelings > Metrics
874. Blah Blah Blah Blah
875. Not Hearing About Problems Doesn't Make Them Go Away
876. Don't Complain Unless You Do Something About It
877. Reaction != Management
878. Everything's Hard Until You Do It
879. Prevention is More Important than Treatment
880. The Best Managers Understand Before They Speak
881. Big Words Just Confuse Managers
882. The Self Fulfilling Employee Treatment Prophecy
883. Solutions Looking for Problems
884. Your Customer's Customer
885. More Solutions Looking for Problems
886. Best Practices Are Neither
887. Possibilities vs. Problems
888. Most Important Thing: The Work of Programmers
889. We Can Never Use Either Word Again
890. Just Fix It. Nothing is Learned.
891. Provide Value. Don't Provide Negative Value.
892. The Role of Money in Decision Making
893. Do Policies and Procedures Well 894. Lead People. Manage Things.
895. What's Management Really For?
896. The Critical Path
Chapter 10 - Culture
899. Quacks vs. Heros
900. Modes of Communication
901. Why Gossip?
903. Getting Fired 904. Tell the Truth
905. Too Many Meetings
906. Busy vs. Accomplishing
907. Necessary Cussing
908. Employee Retention
909. Dogs vs. Cats
910. Remote vs. Onsite
911. Always Tell the Truth
912. Zero Tolerance
913. Meeting Agenda Required
914. Meeting Policy
915. Vaporware vs. MVP
916. Really Caring
917. Cussing vs. Professionalism
918. Cell Phones as Distractions
919. Best Way to be a Team Player
920. 4 Phases of Anticipating a 10:00 Meeting
921. Meetings are My Biggest Pet Peeve
922. Enterprise IT Jobs
923. Corvettes in Mud
924. Nobility vs. Tragedy
925. Too Ignorant to be Pessimistic
926. Having Suffered 927. Best Lesson from My Mentor
928. Crappy Software
929. How to Give Feedback
930. No Interruptions!
931. I Hate Meetings
932. When 15 Minutes = 44 Minutes
933. Converting Good Time into Bad Time
934. Others Must Do Their Jobs Too
935. Email vs. Text
936. Donuts are Stronger that Farces
937. Verbal Requirements Aren't
938. The Fix that Fixes Everything Else
939. Which Half Are You?
940. The Enterprise's New Clothes
942. The #1 Business Problem
943. Most Mission Statements Are Wrong
944. How Quality Has Changed
945. I Have to Make a Difference
946. My Fraternity Litmus Test
947. Judgement by Perception vs. Data
948. Enterprise vs. Start-up Speed
949. Email Strategy
950. Different Views of Meetings
951. Meeting Faux Pas
952. Showing Up is 90%
953. Programmers Need Lots of Time
954. Status Reports Belong in Email, not Meetings
955. Actionable is a Stupid Buzzword
956. Send Separate Emails
957. Many Pieces of Cake
958. Programming Test of Wills
959. Immorality is Illogical
960. Sometimes Perks Are Just Gimmicks
961. The True Test is When Things Aren't Easy
962. Interruptions are Losses for Everyone
963. Screwing Around is More Honest than Pointless Meetings
964. Suffering Often Leads to Overachievement
965. Why Are Programmers So Busy?
966. Who's Responsible for Good Communication?
967. What's Important is Different Places?
968. Forgiveness is Easier than Permission
969. Don't Say What's Goes Without Saying
970. Users Usually Have No Idea What It Will Take
971. Another Backward Corporate Thing
972. We're Busy!
973. Yes is Better than No
974. Involvement != Commitment
975. Customers are More Important than Investors
976. Be On Time!
977. Play Nice and Tell the Truth
978. Good, Better, Best Compliments
979. Be Careful What You Brag About
980. A Bad Mission Statement is Worse than No Mission Statement
981. Bad, Worse, Worst Open Offices
982. Bad Sign: No One Taking Notes in a Meeting
983. The are No Optional Meeting Attendees
984. "Sent from my iPhone" != Excuse
985. Technical Jargon is for Technical People
986. Was Woody Allen Ever in I.T.?
987. Listen or Be Ignored
988. Emails without Data Are Worse than No Email at All
989. The People Who Don't Do Anything Think Meeting = Building
990. Who do Gimmicks Really Motivate?
991. "Should Have" is Impossible Without a Time Machine
992. Morality is Binary
993. Sometimes Enterprise Repels the Best Programmers
994. Opportunity for Achievement > Risk Avoidance
995. Who Gets Things Done?
996. Don't Say What Goes Without Saying
997. What's Worse, Cubicles or Managers?
998. Email Poser Busted.
999. Mission Statements are BS
1000. Why I.T. Can Be Easy
I always carry pencil and paper. It's a habit I learned long ago. I never knew when or where a good thought would arrive. When I didn't write things down, I remembered most of them, but not all. Then I often wondered which thoughts I forgot that could have changed my life.
No more. I capture all of them. I have pieces of paper with thoughts and time stamps everywhere. I've used many of them in my writing, my work, and even my tweets. Of course, I've thrown most of them in my "What Was I Thinking?" box. But you can't toss the bad ones aside if you don't capture them all.
As I read and reread my favorite captured thoughts, I wished that they had come to me many years sooner. How different would my life and career been if they had?
That's when I came up with the idea for this book. I started with the 1000 thoughts that I would have most likely wanted to know sooner. Then I added the "thinking behind the thought" for each one of them. Finally I organized them into logical groupings.
Many of these thoughts appear more than once, only slightly different. That's because I thought about and recorded them multiple times but left them in. So if you think you read something before, you probably did. It's that important.
The thoughts came from everywhere: mentors, workmates, experiences building thousands of things, and of course from the source with no name, often in the middle of the night when I had to pull a cat off my head and grab pencil, paper, and a mini-light.
The thoughts are mine, but not really. I consider myself more of a messenger than a creator. This book delivers those messages to you in a much more consumable package than I ever had. I hope you find one or more thoughts that will impact your life as much as I wish they had done mine years sooner. If so, let me know. My contact info is after every comic strip at EdWeissman.com.
Most people think we sell stuff, but you can buy that anywhere.
What we really sell is service, backed by the ones and zeros we built.
This was one of the smartest things any business person ever said to me and, of all people, it was said by a vice president.
We were a large industrial distributor. We didn't make anything. We just bought and sold it. Our customers could buy the same stuff from our competitors, sometimes at lower prices. So why did they buy from us? For peace of mind. Because we guaranteed every product. We certified everything for specific industrial uses. And we made sure we delivered the right thing to the right place at the right time. This peace of mind took a lot of extra work by a lot of experts, all of it backed by the special software and data we provided.
This was one of the few times a non-programmer actually "got it". The information economy isn't just the phrase du jour; it describes almost all business now. I.T. and programmers are not a necessary evil. We are not burden or expense. And we are definitely not a cost center.
We are direct labor and the ones and zeros we arrange are part of every product we ship. Hardly anyone gets this. And this vice president, not coincidentally, treated programmers accordingly.
I don't hack code. I hack my customers' problems. Code is the byproduct.
The code is not the product. It's the byproduct. The customer's solution by using the code is the product. We programmers often get so into what we're doing that we easily forget this. No one remembers pretty code that doesn't accomplishment much. But good enough code that does accomplish much? Customers never forget that.
Your org chart is upside down.
Those who think they're at the top get nothing until those they think are at the bottom do something.
There are two types of costs in your business, direct and overhead.
Direct costs are what you pay for something that goes into the product that your customer buys. Overhead costs are for everything else.
Direct costs could be raw materials you buy from your vendors and labor to turn those raw materials into a finished good.
Everything else includes all the stuff you need to run your business, but does not go directly into your product. Things like rent, electricity, insurance, and of course, indirect labor.
But what is indirect labor? Anything a person has to do that is not turning raw materials into finished goods. Support personnel. Accounting. Sales and marketing. Facilities. And yes, of course, management.
So what does all of this have do to with I.T.? Everything.
Your product is software. There are no raw materials, only direct labor. And who does the direct labor? Programmers. With a little help from business analysts, testers, and deployers.
Everyone else, while essential, is overhead. Project managers, technicians, admins, and most of all, managers.
If you're producing code, you're direct labor. If you're not, you're overhead. So it's in everyone's best interest to make code producing as streamlined and cost efficient as possible.
Everyone should either be writing code or supporting those who do. In any software producing organization, programmers should be at the top of the org chart with everyone who needs to support them below them.
But how are I.T. org charts normally organized? You got it. With overhead people "at the top" making decisions affecting the only ones producing direct value "at the bottom", the programmers. This is upside down, counterproductive, and by far, the number one problem in I.T.
Turn that org chart right side up and find a way to enable your programmers to produce more. If you don't understand this, GO TO the first sentence and read all of it again.
If you do understand this, then good, you finally "get it". Now do it.
I earn the most when I don't care about the money.
I build the best when I don't have a deadline.
I procrastinate the least when I love what I'm doing.
Whenever I've worked for myself, on every important project, I used this approach:
1. Find a way to identify and do the best thing for the customer.
2. Set my price and do not negotiate.
In Step 1, I never even thought about money. This is key. I spent 100% of my energy on my customer's needs. Only after Step 1 was completed did I think about money, and even then, only enough to set a proper market price. And every single time, I earned much more than I would have as an employee or worse, a business person always looking to "hustle a buck".
The best stuff I've ever built:
- a platform which supported small ERP applications
- a production system for a $400 million manufacturer
- an inventory system for a $1 billion distributor
- most of the software to support 9 small distributors
- a production system for a $100 million manufacturer
None of these were done with a project plan or deadline of any kind. I realize that this is exactly the opposite of what I advise people building commercial software, but I guess that's the point: When building something conventional, build it conventionally, with a project plan and structured approach. When building something that's never been built before, resist restricting the quality of your end product with conventional structure and processes. I always felt like deadlines were a two headed monster: they helped me get things done, but they also caused trade-offs that invariably affected quality. For game changing stuff, sometimes "what" is way more important than "when".
Whenever I don't feel like working on what I should, I ask myself, "Why? Am I just tired or lazy or is my inner self trying to tell me something?" This never happens when I'm doing something I love. So instead of trying to fight procrastination, I wonder if I should be doing something else. Sometimes the answer is, "No, just keep on going," but more often than not, I listen to that inner voice, go with my gut, and work on something I'd rather do. I've rarely been disappointed.
The worst way to end a day's work is at "an appropriate breaking point".
The more messed up things are, the more likely you'll dive back in.
This is counterintuitive and it took me a long time to get this. For high achievers, there's a strong tendency to keep working until something is finished. I always did this, but it hurt two ways. I stayed up too late and had trouble getting going the next day. And I had double trouble getting started because I was starting something new.
Then a mentor advised me to always knock off with something unfinished, no matter how driven I was to keep going. The easier it was to pick it up, the more likely I should just stop. I started doing this and was surprised how right he was. It worked like a charm.
It's a marathon, not a sprint. Keep the string of work days alive is more important that how much is accomplished in any given day.
Why do I work fast? Deadline? Customer? Competition?
Because I want something done before I'm distracted by the next shiny thing.
I work in two modes, slow and fast.
Slow is for analysis, design, and planning. This is because these things create a lot of leverage, good or bad. Do these well and everything down the line becomes easier. Do them poorly, then everything becomes harder. So I make a point of slowing down, being deliberate, and being as sure as I can before moving on.
Fast is for execution (which I'm doing right now). Go, go, go. As long as I'm prepared, I rarely think when I'm writing code or prose. The thinking should already be done. Now I have to get something "in the can" as quickly as possible. It's a whole lot easier to edit lots of stuff written quickly than to have nothing to edit.
My least intuitive tip.
The easiest way to get started tomorrow:
Leave something important and easy to finish unfinished today.
Knocking off at a logical breakpoint is one of the worse things one can do for productivity. When I still have something straightforward to do, that's the best time to stop. It's easy to get started the next day. But when I insist of finishing it that night, I'm often not sure where to pick up the next day. Which is the first step in struggling with progress. Counterintuitive but very powerful.
Note to investors and customers:
Time is to me as money is to you.
Don't waste my time and I won't waste your money.
Time is more important than money. You can get money back, but time wasted is time lost forever. Programmers must guard their time religiously because non-programmers don't really understand it's value. Close the door, reject meetings, and use email for communication. Otherwise you can only blame yourself when others steal your time.
The best predictor of my success is not time, money, resources, energy, or opportunity. It's compulsion.
When I'm working on something I just HAVE to do, nothing can stop me. When I'm working on something I really don't care about but someone else wants me to do, almost anything can stop me. I think the solution to this problem is not to work on my motivation or work habits, but to work on stuff for which I have compulsion. See how easy?
My favorite language? Pseudocode.
1. Everyone knows it.
2. It raises the dialogue from pointless details to real issues.
Every time I try to explain a language independent construct using a real language, the discussion invariably turns to the code itself...
- Why did you do it that way?
- Why didn't you use this syntax?
- What does that mean?
- Why a recursion there?
- Why this process here and not there?
- What is the purpose of this logic?
- Why handle conditionals like that?
Pseudocode + Whiteboard = Generic Discussion, which is exactly what we want.
Difference between optimist and pessimist? Attitude!
Glass half full vs. half empty
Record locked reading vs. writing
I never really understood the use of the words "optimistic" and "pessimistic" in data base recored locking. I guess optimistic expects no one else to change this record while we're holding it and pessimistic expects someone else to try. I prefer transaction based systems with optimistic locking schemes. In any case, every programmer should learn and understand the difference. In large commercial applications, the implications can be huge.
New programming rule:
Make decisions as soon as you have the data needed.
OR... Don't put the If...return 400 lines after the read!
This can kill you! I've caught so many bugs where a variable was assigned, many lines of code, then the variable used for a conditional. And it failed with the worst kind of bug, one that only happens occasionally, is very difficult to reproduce, and has disastrous consequences.
So what happened? Somewhere in the code between the variable assignment and the conditional, the variable assignment changed. It could have happened anywhere, in any one of the called functions or subroutines, perhaps many levels down, under very unusual conditions. It happened in a way the original programmer never could have guessed.
Follow the fundamentals. Sadly, sometimes those who don't never see the bad results they caused. But I do.
My "Big 3":
1. Structure data (memory or disk) properly.
2. Name all variables and functions exactly what they are.
3. Don't Repeat Yourself.
I've always believed that these 3 things cover about 90% of what it takes to build good commercial software. Once the data is structured just as it will be needed, half the code suddenly becomes unnecessary. Properly named variables make it possible for the next programmer to read (and maintain) your code. And not repeating yourself can dramatically reduce the size of your code base. The most easily maintained code is the code you never wrote. Most of the problems in existing code that I've fixed were the result failing to follow one of these 3 guidelines.
A good programmer can get more done than 10 bad programmers, but a bad programmer's code can keep 10 good programmers busy for years.
I was modifying a program that provided an on-line form to maintain a list of products a customer wanted to buy, the vendors who could supply those products, and the current market price for each. It was written by a bad programmer ten years prior. There were many problems with it, but the biggest one was that only one person can use it for any given customer at any given time. It used pessimistic data base locking. It based its locking scheme on the customer, not the part or the vendor.
Then one customer gave a list of 30,000 parts it wanted to buy in 4 days. It would buy all of the parts in the same place, providing that prices were acceptable. We needed 10 different people to update the data base in 4 days, but only one at a time could use it. I'd have to rewrite it completely for multiple people to use and 4 days just wasn't enough time.
So we worked in shifts around the clock and hit the deadline. Years later, the program is the same. Because we don't have enough good programmers available to fix it.
Ever go house hunting and get disgusted at how dirty and sloppy people's houses are?
I feel that way every time I maintain someone else's code.
Why can't we just have minimum universal code standards? You know, simple things like:
- all variables must be Adjective-Noun or Adjective-Adjective-Noun
- agreement on indenting and semi-colons
- no if or case statements bigger than 1 screen
- no code twice, ever
- make all mods with ticket#, initials, date
- no early exits (let the debates begin)
Imagine all the time and aggravation that would save.
You're not writing source code for the compiler or your customer.
You're writing it for the next programmer.
The computer can handle your code. The next programmer can't. Gone are the days when application programmers had to spend much energy worrying about what the computer can handle. Sure, we don't want to do anything stupid (like SQL queries inside iterations), but for the most part, modern computers can process your code so fast that you don't get much incremental value from optimizing it.
The programmer who maintains your code, on the other hand, will often struggle with it. You must make it readable! The price of automated resources continues to fall while the price of people continues to rise. Code to minimize rising costs, not falling ones.
Wanna stop pesky emails from the guy maintaining your code?
Name your variables!
TxnCode, not tcd. PartNbr, not pNo. LoopVar, not i.
Name variables for Baby Bear. Not for Papa Bear, so long that they wrap lines of code. Not for Mama Bear, so short that no one could tell what they mean. But for Baby Bear, just right. Adjective-Noun. Or Adjective-Adjective-Noun. Abbreviated, but not too much. After a little practice, this becomes second nature. Maintenance programmers and Goldilocks will thank you.
Even though I'm getting older I'm writing my best programs ever.
I just keep forgetting what I name them so I can't find them to amend them.
When it comes to aging, a programmer is not like an athlete. When their career is winding down, ours is just getting started. In fact, I've noticed that I keep getting better with age. Each decade I produce software that's much better than anything I've ever written before. I have no idea how long this will last, but as for now, I expect to be programming and producing products for others indefinitely.
To all developers with imposter syndrome: Look on the bright side. As long as you have a manager, you're not the biggest imposter.
For a programmer, "Imposter Syndrome" is when you feel that you don't deserve your credit or reputation because "it's all so easy". This happens frequently. We often earn much more than our users or non-programming peers, but once we reach a certain level, much of what we do comes easily.
We should never feel this way for two reasons. First, don't forget how long it took and how hard you worked to get to this level. Not too many others spent that many hours doing their work morning, noon, night, and weekends. Second, the "undeserved" credit makes up for all those times we didn't get the credit we deserved when we labored away and others didn't understand how hard it was for us to get something done. For me, those times far outnumber the easy times.
I have had good managers who learned technology, satisfied their customers, and when the time came, chose the management career path over development. But there were very few of them. Much more common were "business types" who never really understood most of the things they needed to do their jobs. These are the real imposters.
Debugging something I wrote last month, simultaneously thinking:
"Yikes! This is so complicated!"
"Wow! This is so sophisticated!"
Every time I wrote something "clever", at some point I came back and didn't understand what I had done. But at some other point, I came back at thought, "How cool! What was I thinking or doing when I wrote that? I sure would like to do something like that again."
If I had looked at the source code, I wouldn't have taken this job.
I have never looked at the source code I would be working on for any job I have ever taken. Why not? Because I always thought that this was too low on the priority list. Things that were more important:
- future opportunities
After all these years, I'm finally realizing how wrong I was. I spend all day long in the code. The worse it's written, the more miserable I am. I have written blog posts, forum entries, and even whole books on how to write good code for the next programmer. Why? Because I've suffered with so much garbage. I would not have taken 90% of my jobs because of the horrible source code I had to maintain. On the other hand, maybe it's just as well that I didn't look. If I had, I'd probably be a cook right now.
The delta between a junior dev and an intermediate dev is technical.
The delta between an intermediate dev and a senior dev is non-technical.
I've been asked many times, "What does it take to be a senior developer." I often gave the usual answers, all about technology:
- intimate understanding of underlying logic
- ability to dig and debug
- ability to understand and use databases
- ability to understand and use networks
- ability to appreciate and use great design
- ability to learn and love new technology
Then I realized that I had been wrong all along. I have known and worked with many programmers who were very good at all that stuff and were most definitely not "senior". If it were my business, I would never entrust them with my most important projects.
On the other hand, the most senior devs I've ever known, the ones who I'd trust with my life, also knew the stuff above, not as wizards, but just enough to get things done. The things that distinguished them from everyone else were non-technical skills:
- systems analysis
- project management
- ability to learn and love their users' domains
- good work habits and determination
- knowing the difference between details and real issues
- people skills, often fun, and just get things done
To be a senior dev, you must be good enough at technology and excellent at people skills.
Evolution of Enterprise Software...
1970: 1 homegrown system
1990: best of breed
2020: 1 homegrown system
Funny how some things never change. Or how some things that went out of fashion eventually come back. I like to think that pretty wrappers come and go, but the good stuff inside remains fundamentally true. This is especially true in technology, where the speed of change is so fast, we really need to get good at distinguishing between the steak and the sizzle.
Sooner or later we realize all we really need is good reliable software that does exactly what we need. It was always this way and probably always will be. Whenever that wasn't happening, out industry came out with a million ways to address it, some of it good and some not so good. But no matter what your methodology du jour is, sooner or later, a programmer had to sit down, maybe even at the command line, and build something. See you later.
I always believe WHAT a user claims is a bug.
I rarely believe WHY they think it's happening.
I never believe HOW they want to fix it.
Users are usually very accurate describing what they experience. They know their jobs and they mean well. Unfortunately, they don't always understand the internals of the applications they use that well, so I often suspect their logic in coming to conclusions. And they really don't understand how we programmers go about finding and fixing bugs, so they often way off the mark with their recommendations. As long as I remember this, I can usually work well with them and solve their problems without following too many false leads.
Form collects data, emails it to 3rd party.
Year later, data wanted on report but NEVER STORED in database.
Don't ever do this!
I have an old golden rule: Any report from your app should be able to be run at any time and come out exactly the same. I learned this years ago from an accountant who want to re-run some financial reports from a period several years prior. We could never get it to match what he was expecting. This is not as simple as it sounds. Some to the things you'll have to consider when designing such an app:
- audit tracking of changed data base records
- accessibility of archived records
- date ranges on reports
- filters on reports
- sorts on reports
- saving all selected options for each report run
- identify options chosen on reports
I have extended that accountant's requirements to all reports and have designed ever app to do this ever since.
Every computer generated instruction is also an excuse.
(The computer told me to buy 500!)
ERP systems should suggest and guide, not dictate.
The second worst enterprise applications don't do enough. The worst do too much. We implemented this giant, expensive, world-class, best-of-breed, game-changing inventory forecasting system. It analyzed all the data in the database and made recommendations of actions required by inventory buyers and planners. But there were too many flaws. Inaccurate data. Misunderstood data. Illogical logic. Huge timing issues. And bugs. The humans realized immediately that the system's recommdations were ridiculous. So they ignored them. And used to data from the core system to continue doing what made them successful all along.
$20 million and 5 years later, they finally got the system running but the recommendations were still way off and ignored. Many problems here, but the biggest one? Don't remove the humans from the system!
At sufficiently low level there is no optimistic locking.
It's all pessimistic.
The REAL question: How quickly will you unlock what's locked?
Pessimistic data base locking schemes that have to scale get very pessimistic very quickly. I've seen commercial applications that worked beautifully with 32 users come to a grinding halt with 200 users. Why? Poor pessimistic locking strategy.
One user calls up a master record, locking it, then is pulled away to work on something else without hitting "escape". Others can pull up related data, but then can't update anything related to that master record. This cascades until nobody can do anything. When you design something for x users, think how it would work for 10x or 100x users. You may have to protect your data base with a very different locking scheme.
99% of the projects I've ever worked on had no written Requirements.
Of the other 1%, those written Requirements were insufficient.
In all these years, I've seen about a half dozen business requirements documents that were adequate and thousands that were not. And I know I'm not alone. I believe the reason is simple: because almost no one knows how to conduct and document systems analysis, regardless of how experienced they are or how many initials of certifications they have after their name. The solution is simple, but certainly not easy: Define the Big Fat What. Second only to broken management, I believe this is the most important shortcoming to getting software built. More important than technology, programming skill, project management, or anything else.
1 hour of analysis saves 10 hours of review.
1 hour of review saves 10 hours of testing.
1 hour of testing save 10 hours of maintenance.
No, for those of you who always ask, I don't have supporting data. But I've been doing this for so long, I just have this gut feel.
If you spend the time needed to build good solid business requirement, exactly what is really needed (and it CAN be done), everything else down the line becomes easier. You don't have to stop and go during development for "changing requirements", which are not really changing; it's just their incomplete definition that's changing. Then all the spec review, design review, code review, and peer review catches all kinds of things that are much more expensive (in time and money to catch during testing). And of course, the more rigorous the testing, including regression testing, the less problems in production, the less support and maintenance that will be required.
The further down the line we go, the more difficult and expensive it becomes for fix and change things. All the more reason to spend more quality time at the front of the process. Or as the old oil filter commercial went, "Pay me now or pay me later."
Agile is not an excuse to skip analysis and design.
It's just a way to keep moving when they are incomplete (which they usually are).
No matter how hard we want to work around the problem of insufficient business requirements, it's still there and will remain until we address it. This problem is so widespread in software development, we've found a hundred different ways of addressing it. But no matter what approach we use, agile, prototyping, waterfall, SDLC, VSM, or Business Process Definition, we still have the same task. We must conduct analysis to determine the Big Fat What and design to determine the Big Fat How. We can mix things up, overlap phases, or try new creative approaches, but sooner or later, we still have to know what to build and how to build it.
Every minute spent THINKING about what I'm going to build saves 10 minutes testing it later.
It doesn't matter how fast you go. It only matters when you finish. Sometimes you just have to slow down now to finish sooner later.
So many projects I've worked on have hit that critical road block. You know the one, when we realize that we've hit a dead end and have been doing the wrong thing for some time now. It's kinda like driving from Florida to New York and suddenly realizing that you're in Texas. Obviously this didn't just suddenly happen. Something has been wrong for some time now, but since so many managers lack any time perception, they just fight fires by blaming and implementing a gimmick as a fix.
The real problem is that this was caused by something earlier in the project. And very likely, a lack of planning or thought. During development and execution, speed up and go! But during the requisite planning and analysis, slow down and think! Then you won't have to speed up and go as fast later.
The completion% for every task must be either 0 or 100.
If you can't do that, then your project plan is not broken down enough.
Complete, like pregnancy is binary, either yes or no. I've seen tasks that were declared 90% complete every week for 6 months. In other words, they're 0% complete. The manager would have been better off breaking that one big task into 10 smaller tasks and declaring 9 of them complete. The would have relayed more information, and surprisingly, helped progress by identifying and focusing on the remaining task.
Sometimes I think I can write the code as fast as I can write the technical specs for a junior programmer. But then nothing would be learned.
Other technical leads have asked, "Why should I write technical specs when I could write the code just as fast?"
1. Technical specs in your head cannot be confirmed against the business requirements by someone else.
2. Technical specs in your head cannot be peer reviewed. That peer review can save you a lot of time and aggravation.
3. Technical specs in your head locks you into all of the development. If you need to hand any part of it off, you'll still have to instruct the next programmer.
4. No one else learns anything. No one else grows. So no one else becomes as good as you for future work.
The more I see I.T. and users in separate offices, the less I like it.
SOMEONE has to sit with users full-time time to understand them.
There's no substitute for having your finger on the pulse of what's going on. There's no better way to know whats going on than to be there. There's no better way to be there than to sit with your users, all day long, every day.
When you live what they have to do, what they have to put up with, how they find a way to get things done, and most of all, what they complain about to each other, you get an understanding of their domain that you can't get any other way. Any manager who thinks that you can help determine business requirements any other way has obviously never "been there, done that".
Unfortunately, this is the norm in most enterprises.
Agile without specs is like using a nail file on a hunk of granite.
Think of systems analysis as course tuning.
Documented business requirements take you from 0% of what's needed to x% of what's needed, with x often greater than 50. This is not ideal, but it's a great jumping off point to push that percentage close to 100. Determining requirements before development begins is course tuning. Determining them after development begins is fine tuning.
Switching to agile without some form of business requirements before development is misguided and difficult. You'll always be behind, always trying to learn more about what's needed, very slowly and painfully.
It doesn't matter how good it is if it takes years to implement.
The game will have already changed too much to get planned value.
By the time we implemented a new ERP system, we no longer conducted business the same way that we did when we started. If anything takes more than 6 months, don't bother. Your ROI opportunities will have evaporated by then. Find a way to get every project under 6 months. This is no longer a "nice to have". It's a must. If you don't find a way, your competitors will. Then your best people will want to go there. Worse, your customers will too.
Who is responsible for that?
It's a team.
Everyone is responsible for everything.
So then...no one is responsible for anything.
I have often worked on teams where management wanted to be inclusive; that is, lots of people in lots of meetings about everything: requirements, specs, peer review, etc. I have always sensed an inverse correlation between the number of people in the room and the likelihood that any one of them would respond to a problem. I guess each must be thinking, "Oh, someone else will take care of it."
Corollary: Whenever I ever needed something and I asked multiple people, I always sent them separate emails. They almost all always answered it. If I sent one email to everyone, hardly anyone ever answered.
Deadly advice: "If you can't measure it, you can't fix it."
Many epic failures spent years implementing metrics instead of doing their jobs.
I get it. Everyone has an opinion about things, but without hard data, it's often hard to understand what's really happening and how to approach fixing it. So we need metrics.
There are multiple problems with collecting metrics. First, the collection system needs to be implemented quickly. I've been in I.T. departments that took 18 months to do this. Fail! Second, the metrics have to be easy to collect. When you spend half your time collecting data, you've just created a problem bigger than the one you were trying to solve. And probably most of all, you better be collecting meaningful data. Most timesheet schemes I ever used are the counterargument to that. They're so hard to use that lots of programmers just put in anything. And no one knows enough to question the data. What's the point?
I don't understand why a company with email could have communications problems?
Maintain proper lists. Blast away. How hard can that be?
I've noticed an inverse correlation between then number of communications channels a company has and the effect of its communication. At one of the first companies I ever worked every, everyone sat in the same room full of white boards, facing each other. Hardly anything ever fell through the cracks.
Now we have email, text, voicemail, Sharepoint, Jira, Slack, Confluence, Powerpoint, status meetings, standup meetings, all hands meetings, and town hall meetings and it seems like no one has any idea what's important and what's actually going on.
Oh for the good old simple days when technology supported us instead of getting in our way.
How many meetings are the result of people being unable (or unwilling) to communicate clearly in writing?
Any meeting used by one party to communicate to other parties would be better off by not being a meeting, but an email with an attachment. You know the culprits: announcements, policies, status, all-hands meetings, and of course, the dreaded PowerPoint show. Just send it to me. I'll read it and send my questions.
The real problem is that it's easier to talk than to write. These kinds of meetings are for the convenience of the single sender, not the multiple receivers. And they must cost companies millions because of all the people not working.
Here's an idea for all you managers that prefer talking over writing: Dictate what you want to say in a meeting, have it transcribed by an on-line service, and email us the transcript. You get to do it your way, we get to keep working, and the company makes more money. Everyone wins.
Imagine how much better things would be if we peer reviewed management decisions as rigorously as we peer reviewed code.
Due diligence, peer review, and QA apply to everything. So why in I.T., do we normally only apply it to software? We need to hold every link in the development chain just as accountable: Requirements, specifications, test plans, coding, testing, and of course, management decisions. What often looks like a programming failure was just as likely a failure somewhere else. But we don't know that because programming is the only phase we QA.
Failure to get something built is less about lack of time and more about lack of energy and imagination.
I've heard it over and over again in almost every environment: "We don't have time." This is obviously an oversimplification and rarely true. We all have 24 hours in every day; just look at what some people are able to do with theirs.
We may have higher priorities, but we're not out of time. More likely, we don't think well enough outside the box to find shortcuts, workarounds, or better ways of getting something built. Or we're just too exhausted from the everyday grind of transaction processing.
The antidote: Put one or two people with boundless energy and imagination and few constraints in a room. You'll probably be surprised at what they can do.
The best way to manage something complex is to simplify it first so you don't have to manage as much.
This reminds me of the old saying my mentor taught me: "How do you eat an elephant? One bite at a time." Of course, lots of things we do are complicated. So much so that no one human could wrap their mind around it. But not every project needs to be managed like an Apollo mission. If something is so complex in a world where it doesn't have to be, then simplify it! Most complicated project management systems are the result of taking on too much. Managing 10 simple projects in easier that managing one complex project. So do it and reduce your overhead. It's not a sign of laziness when we simplify; it's an indicator that someone knows how to get stuff done.
1. Me on time.
2. Others late.
3. Cable for projector?
4. Who has Powerpoint?
5. We need Joe.
6. That won't work!
7. Nothing accomplished.
The biggest problem I've ever encountered in any company is broken management. The second biggest problem, which is a direct result, are broken meetings.
Doesn't anyone know how to run a meeting anymore? Meetings aren't 80% as good as they need to be, it's more like 5%. Most meetings aren't needed in the first place. They're just a band-aid for failing to solve another problem. There is rarely an agenda, minutes, leader, goal, schedule, any preparation, or process. But worse of all, people rarely show up on time and some don't even show up at all. These are not isolated incidents; I've witnessed this behavior all the time everywhere I've ever worked.
I've been to many meetings where at the start time, I was the only one there. So I adopted the strategy of leaving. But this led to something that never failed: 10 minutes later, someone came looking for me to come back. This is just a symptom of the terrible way people sometimes treat each other at work with the number one instance of this class being managers showing such little respect for workers' time.
I have open sourced my corporate mission statement.
Feel free to use without attribution.
"Make money by satisfying customers." That's it.
Most corporate "Mission Statements" are baloney and everyone knows it. Sometimes I think that the only thing worse than having one is putting it up on the wall for workers to mock every time they pass it. Forget about synergies, paradigms, strategies, tactics, missions, and goals. And definitely forget about saying things that say nothing, like being the best, the fastest, or the prettiest.
Make money. Satisfy customers. Get to work. (And pay no attention to the B.S. on the wall.)
Why don't you get open honest feedback from your people?
Because when you didn't like it, you accused them of "not being a team player".
Some people are not being open and honest when they ask you to be open and honest. We call these people managers. They value honesty. And loyalty. And team work. They want to have a pleasant, encouraging culture. They have "open door policies". And they do or say whatever it takes to get what they want.
They'll implement gimmicks and games. They'll buy donuts, and lunch, and ice cream. They'll pass out $25 VISA gift cards. And they'll have "all hands" meetings, "skip over" meetings, "product launch" luncheons, "we hit the numbers" meetings, and anything else to lull you into a trap.
That's when you tell them what you're really thinking about them, the company, and our work. And they'll respond by telling you you're "not a team player" or worse. Be careful. When you're under arrest, don't say anything without a lawyer. And when you're employed, don't say anything without a resume.
When you assume the other person has selfish motives, you're right 95% of the time.
But the fallout from the other 5% can be catastrophic.
This pattern invariably repeats with every new manager I've ever encountered. I go to them seeking resources. It could be anything, a meeting with a key person, additional budget, an office, a raise or promotion, the stewardship of an important project, or just the insistence to do something my way (the right way). Every single time they make the same disempowering assumption: he wants this for himself. So they fight me. Why do managers assume that a worker requesting resources is being selfish? This has never made any sense to me. Most of the time the worker is just trying to get something done for everyone's benefit. It's much better to just satisfy them while allowing a few false positives to get something for nothing than to stifle all progress. Selfish, myopic management would rather win an imaginary confrontation than do the right thing. Had sad for everyone.
The day I become "less emotional" about my work is the day I start looking for new work.
One day not long ago, I got really upset at the lunacy at work. This had been building up for some time until I finally reached my breaking point (which was much later than most). I tore into my manager about everything he was screwing up, how poorly everything was going, and how he needed to step up and do his job. I even called him "Nero" and told him to put his fiddle down and get to work.
He didn't challenge anything I said. He must have known that I was right. Instead, he asked me to not be so emotional. That's when it hit me: I love what I do. I do it all day long for years. Of course I'm emotional! If I wasn't, I would be doing something else. There's nothing wrong with being emotional about work. Conversely, I think a lot of problems are because too many people aren't emotional enough.
I finally figured it out:
Every bad I.T. management decision stems from the same root cause: underestimating the value of programmers.
I talk about this a lot. Maybe because it never seems to change. Most I.T. managers I've worked with have a negative assessment of programmers. They refuse to acknowledge this, but they do. They act as if they're thinking, "If they were so smart, then they'd be the manager." Managers continue to make decisions that befuddle us programmers. And almost always when they failed to ask us. For the most part, we know our technology and domain and understand what it takes to get things done. When they make a wrong decision, we know immediately because we've seen if fail so many times before. If only they'd ask for guidance. How much time and aggravation we'd save.
Every nut, bolt, toaster, t-shirt, cantaloupe, chair, pencil, etc. includes 1s and 0s made by a programmer. Be proud (and get back to work).
Being in the "Information Age" is more than just a slogan. It's an understanding that every physical thing is accompanied by digital things. Information, certification, or even just what someone needed to know to get the right physical thing in the right place at the right time. Programmers provided those digital things. The sooner their managers understood that, they sooner they'd become better managers
The thing I always do now that I wish I had always done 30 years ago:
Say exactly what I think.
Oh how much time I would have saved.
I'm always complaining that communication is one of business's biggest weaknesses. People don't say what they should, what they can, but mostly, what they're thinking. I'm just as guilty as anyone of the last one. My mother never had a problem saying exactly what she was thinking. She taught me to do the same, and I did...except at work. Why? Maybe:
- I was worried that I might be wrong.
- I was afraid it would be misunderstood.
- I wasn't sure I could convey criticism positively.
- I would open a can of worms that should stay closed.
- It may not make much difference anyway.
- I was worried about getting fired.
I think that last one gets a lot of people. Things are terrible, but they don't say anything because they figure a bad job is better than no job. But by not being honest with each other, we all suffer in the long run. Problems remain unsolved. Difficulties between people go on forever. Culture deteriorates because of all the phoniness. No more. I can be nice and honest at the same time. And I will. Life's too short for anything else.
My mentor and I were trying to solve a huge nasty bug. It was affecting all of the open sales orders and was causing tremendous problems in the company. We spent all day looking at data, looking at code, testing hypotheses, but got nowhere. Finally around midnight, I fell asleep.
When I woke up the next morning, there were thousands of printed work orders on the floor. He had printed them, laid them out, classified them, reviewed them again and again, entered data into several new spreadsheets, and finally found the problem.
I never would have thought to do what he did. I would have stopped long before he did. I probably would have thought, "That'll never work. Why bother?" I asked him why he did it. I'll never forget his response, which has affected my work ever since, "I didn't know that I couldn't do it, so I did it."