250 Essays from the Trenches

258 Pages

Table of Contents


Reviews for
"The Corporate Programmer Survival Guide
250 Essays from the Trenches"

"Check out Ed's book if you haven't seen it before; he has posted some incredibly insightful stuff over the years, one of the best programming reads I've ever seen."
Jacek Zlydach, Programmer, Krakow, Poland

"Ed Weissman curated his collection of tips and advice for programmers. It is amazing stuff. It is loaded with gems for folks making a living as a programmer. I highly suggest reading it."
Darren Newton, Software Engineer, The Groundwork

"This book from Ed Weissman is a unique book with a unique style, a nice, readable book. Ed is a titan. I hope that everyone, after some training and practice, can be half as productive as he is."
Bartek Filipek, Software Developer, Cracow, Poland

"Read Ed's book, jump out of the bed and start learning."
Kiss Gyorgy, Python Developer and Sysadmin, Budapest

"Follow Ed's style and break down the problem mentally before coding anything. Maybe sketch psuedo code. This will help the interviewer understand how you think."

"I liked reading about programming habits from Ed, especially about reading and analyzing code everyday. His way, I can reproduce much of my entire codebase from my memory."
Akshat Sharma, Independent Consultant, Gurgaon, India.

"Ed Weissman scripts a hilarious (and unfortunately typical) scenario where a critical 1 line change takes 6 days to ship due to complicated and inefficient processes."

"Not to forget another gem from this book that I ardently recall when it comes to self-doubt: 'Don't make the mistake of underestimating yourself.'"
Shubham Jain, Developer, Blipmetrics, UTM-Builder, Whistlerr

"How do I find a 'good' recruiter? Ed Weissman sums it up pretty eloquently."
Steve Buckley, Founder, Hacker Jobs

"'I believe that there are two ways to get good at anything, push and pull.' - Ed. This is a great way to describe different ways of learning. I'll be using these terms again. Thanks."
Matt Chew, Software Developer, Wichita, Kansas

Table of Contents


Chapter 1 - Building

It Takes 6 Days to Change 1 Line of Code
For a programmer, 10 minutes = 3 hours
Insidious Bug or Comedy of Errors?
How do you collect requirements?
How can clever software help customers?
What's a minimalist coding style?
How do you build something piece by piece?
What does a programmer/analyst do?
Programming FAQ
Are these things really that hard to do?
Is becoming a lazy programmer evolving?
How are we making this too complicated?
Can waterfall planning work?
What makes a programmer senior?
Why are relational databases so important?
Is software engineering dead?
Why is BASIC still OK?
When should you rewrite?
How can you clean input data?
10 Signs You're a Crappy Programmer
Technical Debt
Annoyances vs. Requirements
What can be optimized?
Why pre-develop?
Documentation Belongs in the Code
What's the best way to assign ID's?
Why do you hate bad design so much?
Why do you hate old code so much?
What makes code crappy?
How far should automation go?

Chapter 2 - Philosophy

How to Participate in Hacker News
Who is a superstar developer?
Do you think you have peaked?
Why do you program?
What are your hardest learned lessons?
What have you learned from mentors?
Who are the real heroes of programming?
What if I'm not as good as someone else?
It's Never Too Late
It Can't Be Done
How perfect do you have to be?
Are good programmers born or made?
Are programmers expensive?
How far from shore are you?
What is "fear of failure"?
The Code is the Star
How can I be excellent with a day job?
How do you put your skills to good?
Issues vs. Details
How is an issue different from a detail?
Living in Two Worlds
What are the biggest programming myths?
Don't Pull a Teddy Roosevelt
Should I learn or build first?
What's the big deal with startups?
How do you find inspiration?
How to Never Say "No"
Why I'm a Late Bloomer
How does one turn out the way they do?
How important to society is your software?
What is "Intellectual Horsepower"?
The Disconnect Between Us and Them
Weakness or Strength?
Why use a framework?
The Things That Go Without Saying
How do you feel about competition?
Levels of Pissedoffedness
My Favorite Business Quotes

Chapter 3 - Lifestyle

What got you "hooked"?
What Matters Most to a Programmer
Is programming hard work?
Why I Do Not Feel Like a Fraud
How do I become addicted to programming?
Why do we lose our passion?
Why are languages so unimportant?
How does age affect programming?
How much does age affect ability?
My Typical Day
Are you glad you became a programmer?
How much easier is it for an expert?
The Introvert Factor
What athlete are you most like?
Do you need to "sprint" to get things done?
Are young programmers better?
What's the advantage of working for someone else?
Why is it so hard to find programmers?
Is there anything good about my job?
Becoming Senior
What should an older entrepreneur do?
What's hardest about programming?
Where did you learn what you need to know?
Why didn't you pursue mathematics?
Should I keep my day job?
How do you balance work with your SO?
Have you ever been burnt out?
Why were you such a late bloomer?
What do your parents think you do?
Why are some programmers so condescending?
What are the biggest geek myths?
The Programmer's Aptitude Test
Little Known Development Methods

Chapter 4 - Habits

How do you achieve laser focus?
My Working Guidelines
How to you start a new project?
Why do you use such simple tools?
How fast do you work?
How do you work?
How do you stay so jazzed?
How do you make better use of your time?
How do you split your time up?
How do you get unstuck?
What's most important about work?
How do you get things done?
How do you keep track of your thoughts?
How do you boost your creativity?
How do you stay productive?
How do you combat work overload?
Why work more hours?
Why be fearless?
Can programming be boring?
How do you manage your time spent?
How do you capture good ideas?
How do you get good at programming?
How do I rise out of the ordinary?
You're Not the Problem, the Work Is
What are the basic modules in your library?
Why are you a "caveman" programmer?
What tools do you use for analysis?
Every Task is Complete or Not Complete
Why do you love email?
Where do you like to sit in your office?
How important is office space?
How do you pick the best language for you?
What are the advantages of working at home?
Any other advantages to working at home?
How do manage to enjoy working at home?
Working at the Library

Chapter 5 - Advice

not(Advice For Programmers)
What's it like to be a programmer?
How can I get started in programming?
How do I find passion for my work?
How should I learn web programming?
Should I try programming if I'm not sure?
Is this a good way to get motivated?
A Computer Scientist who doesn't want to Code
What should a mediocre programmer do?
Am I burnt out?
How can I find ideas?
Should a systems analyst code?
What's the best way to find ideas?
How do you become a "fearless programmer"?
Should I still be a programmer?
What if my problem has many competitors?
What would you advise your younger self?
What was your startup's biggest mistake?
Should I leave a job I love?
Planting Seeds or Reaping Harvest?
Have I wasted 3 years working for someone else?

Chapter 6 - Careers

"Would my money be better spent on a MBA or MSCS?"
How important is my degree?
Should a programmer get an MBA?
Why don't you think an MBA is important?
How important is a degree in business?
What do you best remember from your MBA?
Why should an MBA learn programming?
What are employers looking for?
How do you prepare your resume?
How to Write a Cover Letter
How good are most job applicants?
Taking an On-Line Aptitude Test
I don't want to take a coding test
What will you do for a prospective employer?
Should I show my code to an interviewer?
Why's it so hard to find good programmers?
Why do coding tests?
Why do a coding test on a white board?
Why do interviewers give code tests?
What is an example of an interview test?
How can I do better on interview tests?
Should I send a Thank You note?
How can a company blow a job interview?
Why doesn't anyone call me back?
Should I go into management?

Chapter 7 - Business

How my High School Job Prepared me for Building Software
Why start your own business?
I'm sooo confused:
The Investor Entrepreneur Chasm
How can I get started?
What went wrong in your first startup?
Why are details so important?
Why are you writing your own software?
When do you say "yes"?
What drives development?
Why would you not launch?
Does consulting hurt a software startup?
What do small business owners care about?
Product/Market Strategies
Differentiate or Die
Are the any advantages for single founders?
How does it feel to be a single founder?
What should a business guy have to offer?
Where can I get help starting a business?
Why should you fire bad customers?
How important are ethics?
Why are ethics so important?
Do you conduct business over meals?
What's your favorite startup book?

Chapter 8 - Enterprise

Good I.T. Manager, Bad I.T. Manager
Bad, Better, Best in IT
Famous Last Words by Bosses I've Had
Willie Sutton would be an Enterprise Programmer
What do enterprise people need to know?
What is a typical enterprise day like?
What's is enterprise IT's biggest fear?
Why do excellent programmers leave enterprises?
Where are there real problems to solve?
How should layoffs be handled?
How do you test drive packaged software?
Have you ever been a hero at work?
Why is SQL so important in enterprises?
How did ERP get so screwed up?
Why is ERP becoming a dinosaur?
How tough is on-line retailing?
Why would we want to go faster?
When can code review be a problem?
Can business software be life critical?
How risky is free software?
What questions would you ask a new boss?
Why do enterprises stifle creativity?
Office Pet Peeves
User Pet Peeves
Do bosses lie?
Left-Handed Baseball Gloves

Chapter 9 - Selling

How important is networking?
How do you find customers?
What do you talk about with prospects?
How should I handle a 1st customer meeting?
How do you tell your story?
What Makes the Top 1%?
Buying Cycles
The Answer is Always "Yes"
How do you crack the enterprise world?
What are the Spending Authority Cut-Offs?
How do you close the deal?
How do I close a sale?
The One Excuse Not to Network


Who am I?

My name is Ed Weissman and I've been programming professionally for almost 40 years.

I've done work for many companies, both enterprises and small/medium businesses. I've functioned as an employee, a contractor, and a vendor. I've worked in many industries, almost always on business systems.

I started out on IBM mainframes, moved to mini-computers, then to PCs, and finally to web-based technologies.

I've started three businesses, two with partners and one alone, selling both services and products.

I've worked with hundreds of people on over a thousand projects and encountered over a million lines of code.

I've witnessed a lot of business and technology, some great, some good, and some not so good. I've always loved what I do and can't imagine doing anything else.

I've formed lots of opinions and freely shared many of them on-line. So I decided to compile my favorite Hacker News contributions back in 2011 as "The Best of edw519". This is the second edition, a continuation of my original project. I've removed some things, added others, and cleaned up the rest.

I never get too technical. There are plenty of other resources for that. Inside you'll find the opinions of someone who's been in the trenches for years and isn't afraid to say what he thinks. Whether or not you agree, understand, or even care, I hope you find something of value. That's the best I could hope for.

Why did I write this book?

Because you asked for it.

I started commenting on Hacker News when I discovered it ten years ago. For a computer programmer, it had lots of cool articles, interesting commentary, and most of all, like minded souls. It became my on-line home - the location may have been virtual, but the results have been all too real.

Little did I know where this would lead...

Thanks for all the interesting discussion and encouraging feedback, both on-line and by email.

Lots of people claimed benefits from my comments and suggested that I do more, either by blogging or writing a book. My response was always, "I do write. I write software." I was always afraid that devoting time to writing prose would take away time from writing source code. It took a while before I realized that this wasn't a zero-sum game; different kinds of writing can compliment and even enhance each other.

The feedback that finally got me over the hump was this comment from an anonymous poster:

"Seriously, have you ever thought about writing a book? I learn something new and valuable every time I read a comment of yours, since your comments almost always contain really good tips. I for one would buy that book for sure." (Thanks, Mom.)

My comments have visited far more interesting places than I ever have:

"Harvard Business Review"

"mixergy" by Andrew Warner

"Hacker Monthly"

"SKMurphy" by Sean Murphy


"allExceptTech" by Ketan Khairnar

"FundFindr" by Bret Conkin

"University of Washington Orthopaedics and Sports Medicine" by Jonathan Jacky

"Why does everything suck?" by Hank Williams

"Sixteenth Letter" by Melissa Chang

"Back of the Envelope" by Mr. E

"Soba Soup"


And finally, some of the nice things people have said about the comments of my on-line persona:

"...edw519, most of his stuff is thoroughly thought-provoking..." - Matt Mazur

"The Best Comment Ever (No, I Didnít Write It)... by edw519, writing an incredible comment on an otherwise unworthy Hacker News story." - Mark O'Connor

"...another great comment from edw519..." - Sigit Nurseto

" excellent follow-up comment at HN by uber-poster edw519..." - D. C. Toedt

"...Ed Weissman (edw519 on HN) had another great comment recently on Hacker News...and he offers a great list of reasons why..." - Sean Murphy

"From Hacker News commenter edw519 comes this gem..." - Andrew R. Freed

"...Hacker News reader edw519 makes a great observation..." by Rams

"And then there are the folks who have such an intelligent and unique voice that you can tell who the comment is before you see their username (patio11 and edw519, to name two)." - Ryan Waggoner

Thanks to all of you. I hope to pass on your positive energy to others in some way. This book is my first step.

How did I write this book?

I built this book the way any self-respecting programmer would: with lots of shortcuts and software.

Notice I said "built", not "wrote". The contents were already written, as contributions to Hacker News, a large on-line community for computer programmers.

What I did:

First, I scraped the interwebs for every comment I ever made on Hacker News and put all 4,000 of them into a hashed database on my c: drive.

Then, I converted the text into something more presentable, removing formatting, control characters, and cuss words. For example, whenever you see "crap" in this book, you can bet that it was something much "stronger" in the original.

Finally, I wrote a program to turn those comments into a usable book. Some of the things that program does:

1. It displays the comments, one at a time or in groups, enabling me to cruise through them very quickly, using only arrow keys.

2. It sorts the comments five ways: by descending number of words, by descending points, by descending date, by descending weight (a secret formula), and in output sequence.

3. It enables me to quickly classify any comment by suitability, chapter, and sequence.

4. It filters the comments by classification.

5. It enables me to drop down and edit any comment.

6. It automatically classifies unread comments based upon similarity to classified comments and some rules. (The idea was to classify the first 300 comments and have the software classify the remaining 3,700. I realized this capability was unnecessary when the book would only contain 256 entries. Oh well.)

7. It cuts the book in multiple formats, ready for distribution.

Like a typical programmer, I often got confused about what the real product was. I spent more time on the software than the contents of the book. Then I decided to get the book out and finish the software later.


How do you achieve laser focus?

The single most important thing I do to "achieve laser focus and concentration" is to work in such a way that I don't need "laser focus and concentration" to get my work done.

This has to be done the night before.

I always quit all online work at least 2 hours before bedtime and print whatever I'm working on. Then I go into any other room with program listings, blank paper, and pens (especially red!) and plan out all of tomorrow's work.

All analysis, design, and refactoring must be done at this time. I do not allow myself to sleep until the next day's work is laid out. I also do not allow myself to get back onto the computer. The idea is to have a clear vision of what I am going to accomplish the next day. The clearer the better.

This does 2 things. First, I think about it all night (maybe even dream about it). Second, I can't wait to get started the next day. I always wake up and start programming immediately. Once I get going, it's easy to keep going. Any difficulties are probably because I didn't plan well enough the night before.

My Working Guidelines

1. Start with the answer, then work back.

2. Name your variables so that anyone will know what they are.

3. Name your functions so that anyone will know what they do.

4. Never write the same line of code twice. Use functions.

5. Assume the user doesn't know what they want.

6. Even if the user knows what they want, assume they can't verbalize it.

7. The user always knows what they don't like. Prototype often.

8. Be prepared to dig down as many levels of detail as needed to understand.

9. When you're stuck, turn off your computer.

10. Don't turn your computer on until you have a specific task.

11. Beauty is important, but delivery is more important.

12. No variable should be fully contained within another variable.

13. All variables should be at least 3 characters long.

14. Use the right tool for the right job.

15. Almost any tool can do the job. Some are better than others.

16. Benchmark often in order to learn what happens under the hood.

17. Try something that's never been done. It may be easier than you thought.

18. Remember the patterns you've used before. You'll use them again.

19. Keep it extremely simple at first. Complexify as you go.

20. Code every day.

How to you start a new project?

How I Write Code:

1. Copy the smallest piece of code I've already written and change it slightly to do something really small. Get it working perfectly.

2. Add a little bit. Get it working perfectly.

3. Add a little bit more. Get it working perfectly.

4. Repeat until it's not so easy to add anything, even a little bit. Print a hard copy. Holy crap! Did I write all that?

5. Mark it up like crazy with a red pen. Combine similar code into common functions. Rename variables. Rename them again. Rename them again. Rename them to what they originally were, but without vowels. Restructure unwieldy functions. Rewrite the stuff I can't believe I actually wrote myself.

6. Sit down at terminal and enter changes. Save every version (even though I never look at it again). Get it to work perfectly (again). Holy crap! What did I do? It's totally broken! Debug, debug, debug. Good. Now it runs perfectly. Time to add more: go back to Step 1. (Except every 5th time through this loop: Scrap it all and rewrite it the way I should have in the first place.)

7. Repeat until dead.

Why do you use such simple tools?

This question reminds me of the greatest cook ever, my grandmother. She used no technology whatsoever. All of her tools had been her mother's which were probably manufactured in the 1800s. She chopped everything by hand in a wooden bowl. If anyone else helped her with the chopping, everyone at dinner could tell. She never used pencil or paper and measured nothing. She stood in line at the farmer's market, the butcher, or the grocery store and inspected every item. And absolutely nothing I have ever eaten since, in any restaurant or home, has been remotely close to hers. It was magnificent! And I miss it so much.

I'd like to think I have almost as much passion about my work. I use the most primitive tools, 24 x 80 green screen editor, no framework, no IDE, no debugger, and mostly pencil and paper. I savor every byte just as I imagine my grandmother savored every little detail of her cooking. I'm not trying to save time or be fast, I just aspire to creating Grandma-quality software. I only hope my software brings someone the same joy her food brought all of us.

I've used many different tools. And I rarely care how fancy they are. Ironically, the simpler, the more joy I have found along the way.

How fast do you work?

Very fast. Let me explain.

I work in 2 modes: (A) At the computer and (B) Away from the computer.

When I'm in Mode A at the computer, I'm cranking out lines of code, testing, revising, testing, revising, etc. This process must be very fast. Several hundred lines of code (or whatever) in less than an hour. A complete cycle in less than a couple of hours. My guideline is that if I'm not working that fast, then I must not be prepared to work that fast, so I don't deserve to be at the computer. I should be in mode (B).

Mode B is much slower. Reviewing code, specs, or notes. Refactoring code. Laying things out with pen and paper. When I have enough work clearly laid out, I know it's time to get back to the computer and return to Mode A.

The most important thing for me in Mode A is to see results, any results, quickly and often. It doesn't matter how correct anything is, just as long as it's progress (or sometimes, reverse progress). I like to think of programming as making incremental progress in micro jumps, evaluate where I'm at, and go for the next micro jump.

Some of the best advice I ever got was from a prolific artist friend of mine who claimed, "I paint every day." So I started coding every day. But that wasn't enough. Now I make progress every day.

There are many definitions of progress. Sometimes I copy a few hundred lines of code, make a few changes, spit out a new app, and then start applying micro changes. Other times I decide that I need to see today and find a way to get there. Things don't always work out as planned, but that's OK. As long as tomorrow's starting point is beyond today's, I'm satisfied.

How do you work?

BIG disclaimer: I have NO formal training.

1. Tools. I generally shy away from tools. I just don't like using anything that makes me more productive when I'm programming. I prefer to type out every line of code, occasionally cutting and pasting from the same program or something similar from the past, but not very often. I want the writing of code to be painstakingly slow and deliberate. Why? Because productivity is not the objective. Becoming one with my project is. I may not start as fast as others, but that doesn't matter. It's not how fast you start. It's how soon you deliver a quality product. Like memorizing a speech, cranking out the code by hand makes it firmware in my brain. It's not unusual for me to crank out 300 lines of code and then be able to reenter them on another machine from memory. So when it comes time to debug, refactor, enhance, or rework, those cycles go very quickly; that code is already in my brain's RAM and it got there the hard way.

2. Simple Algorithms. Yes! I love this example:

* EnterOrders 08/31/10 edw519


I now have a working program! You say you want more features? No problem. Let's start enhancing it.

3. Debugging. I don't. I've seen 25 different debuggers and I hate them all. Print() is my friend, especially beyond the right fold. Better yet, write code that doesn't need to be debugged (See #1 & #2 above.) (Of course, this is much harder with someone else's code.)

4. References. Don't need no stinkin' manual. I have become extremely adept at about 4% of what's available to me, but that 4% accomplishes 98% of what I want to do. (OK, I'll refer to a manual when I need something from the other 96%, but that doesn't happen too often.) We could talk about all kinds of other things too, like variable naming, how to iterate and branch, and never typing the same line of code twice, but this was a nice starting subset.

How do you stay so jazzed?

Wanna know the biggest difference between you and me? I'm pulled. You're pushed. Let me explain:

I love building stuff. Nothing gives me a bigger rush than getting something working the first time. But I couldn't care less about the technology. If an abacus, two tin cans on a string, or some BASIC code on a Kaypro II did the job, then that's what I'd use.

What I really care about is how my software is used. And who uses it. There's an endless stream of people who need stuff and an endless stream of problems to solve. For individuals, groups, and businesses. When I encounter a new problem to work on, I use whatever I can apply in my tool box. Sure, I have to upgrade that tool box every so often because I need more to solve my problems, not because I love the toys so much.

You sound like the opposite. You love the toys and look for places to use them.

My suggestion: Take a break from the technology and put yourself in more situations where people can share their problems. This will give real human meaning to the technology. I bet you'll be chomping at the bit to build something for someone in no time. For me, being pulled by a demand motivates much better than being pushed by a supply. Maybe it can be for you too.

How do you make better use of your time?

"Work effective hours, not necessarily long hours:"

The best trick I have ever figured out for doing this is to separate all activities into "in front on my computer" and "away from my computer". If you are working ineffectively in either mode, switch modes. If you are still working ineffectively, consider a break.

I often sit in front of my computer, writing code, refactoring, or testing and realize that I'm getting nowhere. Then I conclude that the reason I'm not making progress is because I'm not quite sure "what" to do.

Determining what to do is an activity that I have found much more effective away from the computer. So I log off, grab pencil and paper and go somewhere else, anywhere else. As soon as I have something I'm sure I want to code, then (and only then) do I return to the computer.

This works both ways. If I'm away from my computer, but feel I'm not creative enough, then I just decide to write something, anything, and go write it. Sometimes just getting the smallest things done opens the doors to getting bigger things done.

How do you split your time up?

I'm guessing my split would be like:

sales & marketing - 10%

analysis - 15%

design - 5%

development - 50%

implementation - 10%

support - 10%

Testing is not a phase, it's included in everything. Implementation includes deployment, training, and documentation.

Sales and marketing were never problems. There is business everywhere. I mention what I do everywhere I go (who doesn't), and find business almost anywhere. Everyone uses software these days and everyone needs something. I've gotten 5 figure deals at parties, family functions, networking events, and mostly from word of mouth.

I love to program, but I also love to talk about what I do. I may not be typical, but isn't helping people with cool tech what it's all about?

In my mind, the problem isn't the time needed for selling and marketing. The real problem is that this kind of business (consultingware, one-off packages, lite package with customization, whatever you want to call it) isn't scalable.

If my competitive advantage is better value because the boss (not some lightweight on an 800 number) is supporting you, then it's also my biggest limitation. I only have so many hours in a year. Sure, I can extend myself with advanced methods and technology, but sooner or later, I hit my limit. That's why it's so important to find a way to convert your consultingware business into a product business. Not an easy feat, but surely worth the effort.

How do you get unstuck?

Some of the things that have worked for me:

- Decouple analysis from coding. There are some things that should NOT be done in front of a terminal. Get a pencil and paper and go somewhere else. By the time you're done, you'll have plenty of stuff to code. (I have found that the main reason I get stuck is because I haven't spent enough time away from the terminal laying things out. I'm always in too much of a hurry to get back to work before I'm ready.)

- Get a customer. They'll give you something specific to work on. If it's maintenance, all the more reason to get to just dig in and get to work.

- Ask yourself the question, "How am I making this too hard?" If you listen to yourself long enough, you'll probably get a good answer and a fresh approach.

- Reduce scope. Remove outlying cases. Solve only for the most probable case. Get that working perfectly. The process of doing this will probably shed a lot of light on how to set up structure that will also handle the outliers.

- Back up your current version and the go wild on it with some crazy approach. Knowing you have a good backup frees you up all the more. At the end of the day, if you have something cool, keep it. If not, just restore your backup and throw away today's work. You may have wasted the code, but you didn't waste your time. You probably got the juices flowing again.

- Backup your current version and forget about it. Wipe the slate clean and start over completely. You won't have to worry about satisfying all the overhead you've already created. After a day or two, keep either the original version, the new version, or more likely, you'll have a new project: combining the best of both. In any case, you'll be busy working again.

- Set the project aside and work on something easy and fun that no one needs and provides little value to anyone. The byproduct is that suddenly, you'll discover you're working and enjoying it. The next thing you know, you'll want to go back to the more difficult project.

- If you're stuck on something, post your dilemma on-line. Read the responses. You may get a different approach that you can play with. And even if you don't, you won't feel so alone. That may help.