edw519

True for everywhere I've ever worked.

Imagine how much better everything would be if we prioritized this problem before all the tech orgasms.

When I read that sentence, I gasped and thought the same thing.

I've spent a career writing thousands of lines of application code that would have never been needed if the database had been designed properly. But it wasn't because the deployer didn't think they needed "deep knowledge" that day.

We stand on the shoulders of giants who figured out the fundamentals just for us.

The worse the violation (different data types in the same column, ugh!), the more application code (10X) will be needed.

The more code written, the more more maintenance (another 10X) needed.

And none of it ever gets replaced, just migrated to something else years later (if we're still in business).

ASIDE: As for the interview question, I would never ask what "ACID" meant. I'm more interested in understanding than recall. I would just give the candidate a poorly designed database and ask what they would do to fix it.

Me too. But I'm trying to quit.

It's true that I don't comment much anymore, but remember, when someone who used to comment with so much energy before slows down, it's probably because they're so busy with the stuff that made them comment in the first place.

I'll be back. Promise.

Thank you! :-)

The concept may be timeless.

The positive energy that made me do this is definitely timeless.

I'm still here.

Thanks for reminding me why, sorokod.

Best wishes, edw519

The web / startup / open source / constantly changing world of continuous learning and building solutions looking for problems.

And the enterprise world of minimizing risk, meeting all day to kick real problems to someone else, and staying just far enough below radar to keep direct deposit and 401Ks humming along.

Make no mistake about it: Microsoft OWNS the enterprise world and has for 25 years. These people know little else. They do Webex and Skype, not zoom or slack. They use Microsoft Project and Sharepoint, not Trello. They outsource or purchase e-commerce, HR, and supply chain. If any programmer knows anything not Microsoft, they're either "not a team player" or "a god". Hell, even one CEO once told me, "I do not allow my people to use I.T. as an excuse. They have Excel." That's pretty much the thinking and I don't see any evidence that it's changing anytime soon.

Any enterprise people here have similar experience?

Go back and read all his essays. You'll learn more than if you got your MBA. (I know. I've done both.)

Believe me, I'm not PG fan boy, but he doesn't have to do this and I hope he never stops.

I can think of no better example of this than Hacker News.

Years ago, independent-minded people came together for the liveliest "out of the box" discussions on the internet.

Eventually those people started to get shouted down until sadly, many of them left.

I wish I knew what to do about that. I imagine people way smarter than me have been struggling with this for some time.

Over the years, I have bumped into fellow Hacker Newers in all of these places.

I didn't realize how spoiled we must be here in Miami (but not at the moment). Thanks for the reminder, throwaway!

They usually know "Why".

Then never know "How".

So, the "What" is theirs, the "Why" is ours, and the "How" is mine. All documented and agreed upon before a single line of code is written (except for a prototype, wireframe, or proof of concept).

Take the time and energy to do this up front or stop caring. Your choice.

I read the sample chapter and enjoyed it so much, I bought the book on gumroad. But ONE BIG NIT: the sample chapter is pdf, but the book is not. Can you please provide me a pdf of the full book? Email on my profile.

Looking forward to reading the rest and providing feedback.

I hope you sell a bunch of books and write some more :-)

Either you're getting your work done or you're not.

Any other way of measuring abuse is management malpractice.

Where I work, discussing salaries is strictly forbidden and grounds for dismissal.

I demanded an increase and was told, "No. It wouldn't be fair to the others."

I asked, "How would they know?"

(weWantToBeFair) = enterprise(iWontCumInYourMouth)

My experience is that technology has never stood in my way. It may be inconvenient, but I always find a way to work with it.

The thing that has always been in my way is other people. Always.

For me:

1. A boss who has a clue. Who has actually built software deployed to production at least once. Who understands the customer's business. Who manages things and leads people, not the other way around. Who gives me my assignments, the resources I'll need, and leaves me alone.

2. Project managers who know how to run projects.

3. Business analysts who know how to conduct analysis.

4. The decision to either go agile or not. No more sprints, stand-ups, scrum masters, product owners, retrospectives, etc, etc, etc, unless we do it completely and do it right.

5. Anyone, anywhere who writes something, anything down. No more, "Don't you remember when Sue asked Michael and he got Fred to tell us in that skype?" (My answer is always, "No.")

6. Any environment where I spend 90% of my time programming and 10% on overhead, not the other way around.

7. Authority to go along with my responsibility. I'm tired hitting every deadline and forced to wait weeks (or months!) for Peer Review, Code Review, Design Review, Standards Review, User Acceptance Testing, Integration Testing, Quality Review (against what standard?), Steering Committee approval, Leadership approval, approval from God herself...

8. A minimal acceptable competence level for my teammates, achieved by proper vetting (including tech interviews and tests). Software development is achieved as fast as the weakest link, not the strongest one.

9. No meetings!!! If it isn't written down, it isn't. If it is written down, you probably don't need to meet.

I could go one all day, but I'm late for a meeting. :-(

How hard would it be to get your phone to transmit gps coordinates you choose, not where you actually are?

How hard would it be to override what tattleware sends your boss with what you want it to send?

We always knew that's bad bosses never understood this.

It's just sad to see that now there's a market for it.

Programming off and on for over 40 years. Left several times. Because nothing is as fucked up as I.T.

Did sales, consulting, several small businesses, and writing. Kept getting sucked back in. Because no one else digs as deep into things as us programmers. Became frustrated because we were always "skimming on the surface" of everything instead of deep diving into the cause instead of the effect. Besides, nothing turns me on more than watching something I built from nothing working for the first time. I haven't found that feeling anywhere else.

What do you do now?

Back into enterprise programming. Should be having a ball, but I'm more miserable than ever because of the total fuckedupness of management. Planning my next one-person business now.

Any regrets?

No. I had choices but picked programming. I often wonder how my life would have been different if I had become a mathematician, teacher, writer, artist, musician, or something else. But every time I talk to friends who went in those directions, I realized they had their own shit to deal with and I followed exactly the right path meant for me.

And how come you still follow HN?

Because my "Delete Programming from my DNA" button returns a stack overflow.

This has nothing to do with technology and everything to do with people. For all the progress we've made with technology in the past 50 years, we've made little or no progress with any of the items in this list.

The second biggest problem building software has always been programmers too small for the task at hand.

The biggest problem has been managers who are even smaller.

So don't blame COBOL or any other technology. Fix the people and you can build anything excellent from almost any tech.

Myron said, "I see that Lee Flowers is playing today after a high ankle sprain 2 weeks ago. But I thought that high ankle sprains took 4 weeks to heal. What gives?"

Coach Cowher replied, "4 weeks is true, Myron, for the first high ankle sprain. But if you recall, Lee had a high ankle sprain on the same foot last year. And since subsequent high ankle sprains only take 2 weeks to heal, he's ready to play."

Myron paused and asked, "Then why don't you just take the whole team out in February and sprain all their ankles?"

(We laughed 20 years ago. Nobody's laughing today.)

2. The HOW should be something very important to you.

Many experts tell you that you should build something that you actually need yourself. That may be good advise for start-ups but not as good for side projects. Why? Because it's too damn easy to just give up as soon as you hit an obstacle (and you WILL hit obstacles).

But when someone else is depending on your work (and becomes a trusted collaborator), they provide you with that extra UMMPH you will undoubtedly need when the going gets tough. It's a lot harder to bail out when someone is right next to you and depending on you.

But by deciding on your own HOW you will build it, you maintain an outlet for your passion. Believe me, I know. For me the journey of building something is more fun than the anticlimactic using of the finished product.

Works all the way around. Give it a try.

Those of us with I.T. managers have been putting up with this forever:

https://en.wikipedia.org/wiki/Dunning%E2%80%93Kruger_effect

It's easier than most people think.

That would open up a whole bunch of possibilities that no one is looking at. Much better than competing with 2000 others at the next soon-to-be-obsolete app.

I've built a great career by asking customers to consider the "low tech solution" first, then building upon it. Amazing how often they love it so much that the "building upon" step never comes.

As I sit here on a client's system with 14 useless windows open, being bombarded by skype, email, voice, chat, webex, outlook, office, text, jira, confluence, and sharepoint notifications from 14 others with their own 14 useless windows open, none of us getting any real work done, I wonder why 2 guys like you who know how to get shit done don't come in and just fix this for us.

It has had nothing to do with choice of technology, industry, physical location, contacts, or luck (I think).

The only common denominator I can cite is finding out what people (customers or employers) really need, figuring out how to build it for them, consistently building it, and staying friendly and helpful throughout.

Do that and nothing else matters. Don't do that and keep worrying about it. It's that simple.

Great advice! I'd take it a step further: we need more good writers working on the documentation that's needed before the code is written. Call it Business Requirements, Functional Specs, Technical Specs, Stories, or whatever, almost everyone sucks at it and almost every project suffers by the lack of it. No one reads documentation written after the fact (it's not sexy), but projects are saved and careers are made by those who can write anything that helps the people actually building the software. I may be a little weird, but I think that's very sexy.