edw519

This could make great bulletin board material in some other format, but there's just too much here for that.

I started my reply by cutting and pasting the gems with my little follow-up, but quickly realized that would take all day. There just so much good stuff here. So instead I narrowed it down to just one:

Code is humans to read. ALWAYS. Optimization is what compilers do. So find a smarted way to explain what you're trying to do (in code) instead of using shorter words.

This really strikes a nerve because in 40 years of programming, most of my problems have not been with building code myself, but with trying to figure out what my predecessor had written. I bet I've wasted 20 years of my life refactoring the crap of others who would have benefited greatly by reading posts like this one first.

There's lots to think about. Lots to smile and agree with. And lots to disagree with (OP reminds me a little of myself, a caveman who often claims to know "the one right way" :-)

If you don't have time to read this now, bookmark it and come back later. One good idea from this can make a big difference.

After spending 7 million years (it sure seems like it) cleaning up the most vile garbage code you could possibly imagine, I'd like to elaborate on this:

Architecture is more important than nitpicking. While a small line of code could be improved, the stuff that tends to cause bigger problems down the line are usually architectural. I should’ve focused more on the structure of the application than tiny bits of code early on.

Architecture = the sum of all those seemingly unimportant "tiny bits of code".

It seems like every time I have to refactor or (heaven forbid) rewrite, I have to start deep down in those tiny bits. I've worked places with all these "genius" architects, but when I dive deep down into the code, I find a sewer than couldn't possibly support software life as we know it, no matter how brilliantly it was conceived.

Fellow programmers, you probably know exactly what I'm talking about, all those cancerous tiny bits that kill even the strongest patients:

  - variables so horribly named that no one could ever interpret them
  - 800 line iterations surely destined to be broken by a maintenance programmer
  - conditionals so illogical that no one can tell if they ever worked
  - early exits to hell that can only be fixed by rewriting
  - double negative logic that could not never fail to break
  - 8 lines of code where 1 could do
  - <add your own>

Get good at the trees and the forest will flourish.

There are obviously many pros and cons, but in my experience, there is one huge overriding factor most likely to determine remote success: workers' ability and willingness to read and write.

In my most successful remote relationships, almost everything was written down, written well, and read well. I'm talking about all the usual suspects: business requirements, functional specifications, technical specifications, project plans, stories, post-mortems, meeting agendas, code reviews, and of course, test plans.

But then again, this has little to do with working remote. You MUST write all of these things down anyway: I have witnessed over and over again a high correlation between writing and reading well and project success, remote or not.

If has never really mattered what methodologies or tools were used (yes, email is fine, so are waterfall and agile). You HAVE to write things down in the software building world.

Using this line of thinking, remote can actually make your team more effective. You have to get good and reading and writing to succeed. You have much less option of meeting, or huddling, or whatever they call those crutches these days. Write it down and all that fluffy overhead goes away.

Wanna go "remote-first"? Learn how to "read-and-write-first". The rest is gravy.

The best advice I ever got from my mentor: "Listen to your gut!" Passing it on...

I have enough savings to survive for five years.

What?!? Are you fucking crazy?!? What are you waiting for?!?

My biggest fears are: - To not stick to a schedule/routine once I am solo.

How will you know until you try? More to the point: how will you know how important "sticking to a schedule/routine" is until you try? (Probably not nearly as much as you think.)

- People's and family opinion.

Fuck. That. Shit. The first thing anyone must do when embarking on a new journey is to focus on the issues and ignore the pointless details. I can't imagine anything more pointless than "people's and family opinion".

- Failing and losing motivation. Why lump these 2 together? In my experience, failing is the best way to learn and learning is the best way to get more motivation.

Should I quit my job and work on my stuff or search for another position that would give more motivation?

YES! YES! YES! Do something, anything different! The worst thing you can do at this point in you life is stay the course. You'll just get older and more bitter. And posting the same thing on hacker news 2 years from now.

You can recapture money. You can recapture relationships. You can recapture your health. You can recapture almost anything, except for time.

Please don't make the same mistake I made by getting started in your 40's. Because you were too timid and pissed away too much of your life on what you know is the wrong thing.

I've responded to many similar questions over the years here on hn, but yours may be the clearest of them all: You already know what you must do but came here for confirmation. Now you have it. Take the next right step for yourself and please, keep us posted.

Best wishes and respect!

You shouldn't be looking for resources, steps, advice, pitfalls, experiences, or anything else.

You should be looking for a customer whose hair is on fire.

Then, and only then, should you be looking for whatever it takes to build them a fire extinguisher. Anything else is a waste of time.

OP brings up a lot of good points (who could argue with these), but overlooks my #1 fundamental: If you can't write good code, not much else matters.

I know lots of programmers who have mastered the technical skills but are weak at the other things, so no one would ever mistake them for "senior", no matter how good their code is.

But I know many more "I.T. people" who are good at the "soft stuff" (analysis, design, product ownership, people management, agile, etc.) but can't code. I don't want to sound snarky, but these people are a dime a dozen. They often have great attention to detail and patience, but would you really entrust them to build your software?

Learn how to build software first. Be able to do that well before adding the soft skills.

That's the most important software dev skill needed. And it is most definitely "technical".

  1. Keep the changes small and focused
  2. Ensure logical coherence of changes
  3. Have automated tests, and track coverage
  4. Self-review changes before submitting for peer review
  5. Automate what can be automated
  6. Be positive, polite and respectful

I've always believed there are 2 levels of code review, defined by their deltas:

1. Review against standards, defined by the delta between the code and shop standards, which should be well defined for everyone ahead of time. Things like formatting, white space, variable naming, conditionals, iterations, standard modules, etc. Every shop has (or should have) a standard way of doing a lot of these things. Much of this level of code review can be automated.

2. Review against expectations, defined by the delta between the code and the technical specs. Of course this requires technical specs which many shops don't do. If you write technical specs, and peer review the specs, agreeing that this is what is expected, then this level of code review becomes much more straight forward. This includes things like business rules, logic, data base updates, UX, interfaces and APIs with other apps, etc. This is much harder to automate, but offers a checklist to streamline the review and keep it objective. It also makes User Acceptance Testing easier down the line because code review has already eliminated a large subset of potential UAT rejections.

I'd love to hear how others handle these 2 levels of code review. Now that would be much more valuable than this list of feel good platitudes offered by the OP.

I couldn't even make it the 3 months. They didn't either. Their customers' lawyers were more agile than they were.

Keep restoring the original and repeat. Then start adding new functionality. Experiment. Break it. Play "what if". You can always restore and start over.

Before you know it, the mystery starts to fade and for some people, the fear does too.

Just do the right thing. Always. If you're not sure what that is, figure it out however you can, and do it. This time. Every time. Always.

Once you start doing that, all the other BS melts away.

A few personal thoughts of what "the right way" means in IT:

  - Treat everyone else like you want to be treated. No "talking down".
  - Got Business Requirements? Are they any good? That may be your problem.
  - Same thing for Technical Specifications.
  - Same thing for Test Plans.
  - Is everyone working on their most important thing? Why not?
  - Will it affect the annual report? Yes? It's an issue. No? It's a detail.
  - Keep the process that's needed. It helps.
  - Ditch the process that's not needed. It hurts.
  - Go with your gut. That's what got you here.
  - If it needs changed, change it. If you don't, it'll change itself some other way.
  - Correlation != Causation.
  - Know the Critical Path.
  - Keep your finger on the pulse of everything you can.
  - Programmers produce. Everyone else must support them. (Never forget this!)
  - If it's not written down, it's not.
  - Relax and have fun. Can't? Find another career.

The technology has always been easier than the people. No surprise that has affected his "business" too.

There are 2 kinds of learning: "Push" and "Pull". "Push" means you find learning opportunities and "push" them onto whatever you're building. "Pull" means you have something you have to build but don't have all the personal resources you need, so you "pull" in what you need as you go.

You're problem is that you're a "Pull" learner using a "Push" approach. The result is that you haven't learned deeply enough because you're pushing what you have so that permanent deep knowledge hasn't successfully transferred into the firmware of your brain. When you "pull" knowledge, you're applying it immediately in a deep, permanent way and you're much more likely to get all the value from it.

How do I know you're a "Push" learner? Easy, your language. "Coding challenges", "tutorials", "videos" are classic examples. Nothing wrong with these when you need them (by "Pulling"). But when you "Push" them into your brain you get the classic result: confusion, over complication, frustration, and eventually, anger. This is a common problem. You are not alone.

I am the opposite, a classic "Pull" learner. I bet I don't know more that 20% of the syntax of any technology I know. I've written over 2 million lines of code in over 1,000 successful projects but I've only written about 15 programs from scratch. I really don't care about how much I know or how good I am; I only care about getting the job done and satisfying my customer to get their job done with my tools.

Like I promised, your solution is simple: Find someone who needs what you're building and then find a way to build it. That's it. Trust your inner self to find what you need, learn it, make it work, and the internalize it.

The sooner you stop worrying about your problem and start worrying about your customer's, the sooner you solve your problem as a byproduct of solving theirs.

Give it a shot and let us know how it goes.

Seriously. Believing in the mission is the first step. Acting upon it is the second.

I bet nothing ingratiates you as much as this. It shows them that you "get it", are serious about your own aspirations, and are willing to do whatever it takes to get there. And it will probably open every little door and window just a little bit further.

Helping the Steelers win? Finally! Something that really matters!

</sarcasm (do I really need this tag?)>

Great advice if you want a miserable 40 year career as a team player in mind numbing corporate work prevention departments.

Bad advice if you want anything more out of your programming career.

Horrible advice if you want to make a difference by sharing your gifts with those who need them.

You don't get that many chances to do what OP did by jumping in and making dramatic improvements.

The only reason I have ever avoided staying the hell out of legacy code was when opening that can of worms was just the wrong thing to do for everyone.

Otherwise, I got the hell in there.

Sometimes I was thanked.

Sometimes I was reprimanded.

Sometimes I was fired.

Always I learned something, usually the best learning I ever had.

(And as for getting fired, I wouldn't have changed a thing. This is actually a good thing. Better to push the limits, find out who you're dealing with, and move on quickly rather than being miserable for years without ever understanding why.)

The Best Programming Advice I Ever Got? ... Always Do the Right Thing. (Even if it takes a lifetime to figure out what that is.)

Then you sign up and find out 2 weeks later that your fellow attendees at the loss-leader conference are your trainers at the big gig.

How I have dealt with it:

1. Never complain. Never bad mouth any of my predecessors. Whatever they did wrong, I probably did somewhere else just as badly. We all have.

2. Never be bashful about what is wrong. Be objective. Be specific. Keep asking questions until there are no more answers.

3. Become the new expert. Don't depend on "higher-ups" for too much judgement. Convincing them should be about as hard as convincing a mother that her bleeding child needs a band-aid. If they need convinced, they are part of the problem.

4. Long conference room tables, paper, scotch tape, and multiple colored highlighters are your friend. Others thought I was crazy, but I have had to paper table and walls with technical debt to a) understand better and b) have everyone visualize what we're up against.

5. Don't be afraid to rewrite anything with a couple of caveats: a) Do it in less that a week. b) Do it only to understand it. Plan to throw away what you rewrite. c) If you can use what you wrote instead of what's already there, that's gravy.

6. Priority of what to learn: a) The data base. b) The code. I have even written utilities to scan and label data to understand what the hard disk looks like before ever venturing into the code mess.

7. Priority of things to refactor/rewrite: a) Rename variables EXACTLY what they are. This can be very difficult but will probably give you the biggest bang for the buck. This step often opens the flood gates for everything else. b) Remove duplicate code and modularize. c) Reduce long conditionals. 800 line case statements suck. d) Remove early exits. The idea is not to improve the performance of the code, it's to understand what it's doing. Multiple exits can be very confusing. e) Fix white space, maybe more, maybe less. The process of doing these things almost always provides better learning that just reading it. Sometimes I have had to rewrite something and then throw it away just to understand what we have.

8. By the time you reach this step, you probably know more about what we've got, what our problems are, and what the speed bumps will be in the future. You probably won't have to convince anyone to do anything except come to start seeing you as an excellent resource.

9. <sarcasm> Bitch about all of the above at home at night. You may ruin your marriage, but at least you'll still have a job. </sarcasm>

My heroes have always been those in the background who were more concerned about getting work done than talking about it.

I can think of no better example than Paul Allen.

So sorry to hear this. R.I.P.

https://www.pbs.org/kenburns/civil-war/

https://en.wikipedia.org/wiki/The_Civil_War_(miniseries)

1. "I only worry about 2 things: getting our work done and keeping our people."

2. "Every senior dev I hire must have done one of two things: either ran their own business or was a one-person shop. That's how I know that they know how to do whatever it takes to get software built and deployed."

3. "Our customers can buy this stuff anywhere. They buy it from us because of the value we add. That value includes the ones and zeros that we developers add to every product. The sooner everyone understands that, the sooner they will see I.T. as an indispensable component of our product and not an overhead department."

  1. % time spent programming, % time spent not programming?
  2. On a scale of 1 to 10, how much do you love your job?
  3. The biggest thing that would raise answer to last question?
  4. On a scale of 1 to 10, the quality of the business requirements you receive?
  5. The biggest thing that would raise answer to last question?
  6. On a scale of 1 to 10, the quality of the technical specs you receive?
  7. The biggest thing that would raise answer to last question?
  8. On a scale of 1 to 10, the quality of the dev environment?
  9. The biggest thing that would raise answer to last question?
  10. Avg length of time from dev complete to deployed into production?
  11. If you had not picked this, what would you have picked? Why?
  12. Biggest regret from this job?
  13. Biggest success from this job?
  14. How much longer to you see yourself working here?
  15. On a scale of 1 to 10, the quality of the existing code base?
  16. How far to closest Chinese buffet?

This is NOT normal and should not be accepted as such.

I'm 63 and have been programming professionally for 40 years. I'm currently working on several projects that are as complex as anything I've ever done. I honestly feel that that I get better every year, build stuff I never imagined a few years ago. I know this is subjective, but I feel like my brain is faster, I have more stamina, and better memory than ever. I still do newspaper jumbles and crossword puzzles without a pencil and plan to continue that way indefinitely.

Unless you're managing a serious medical condition, I suggest you do something differently: eating, exercise, lifestyle, medical care, something.

To you kids out there (under 50), do not despair. The best could be yet to come if you make it that way.

  2007
  High school acquaintance: Join us on facebook!
  Me: What for? So you can treat me like shit like you did in high school?

  2008
  Cousin: Join us on facebook, so you can stay in touch.
  Me: Why don't you just tell me what's happening like you always have?
 Then we can shoot the shit and laugh and talk and gossip, just us two, like we always have?

  2009
  Neighbor: Why don't you join our community group on facebook so you can see what's going on?
  Me: I'll just pay my dues and spend my time on what's really important to me.

  2010
  Work associate: Why don't you work at facebook? Everywhere else is lame.
  Me: Because lots of other places are doing cool stuff that really matters.

  2011
  Friend: I can't believe you're still not on facebook. Everyone is!
  Me: Your 2 sentences contradict each other.

  2012
  Me: Why didn't you invite me to your wedding?
  Fraternity brother: Because you're not on facebook.
  Me: Lame. And classless.

  2013
  Sister-in-law: Your business cannot succeed unless it has a presence on facebook.
  Me: Really? I just had my best year ever.

  2014
  Local business: See what we're up to on facebook.
  Me: I just go somewhere with their own website.

  2015
  Me: Why didn't you answer my emails?
  Friend: Why didn't you just message me?
  Me: What's that?

  2016
  Work friend: How do you manage to get so damn much work done?
  Me: Because I'm not spending hours every day on facebook on my phone.
  I'm too busy building stuff.

  2017
  Business guru: A following on facebook is not nearly as effective as a good email list.
  There's too much noise for the signal.
  Me: You don't say?

  2018
  Almost everyone: What have we done?!?
  facebook is ruining everything!
  Our privacy is gone! How do we get off?
  Me: I get off every day. The old fashioned way.

This is perfectly consistent with 99% of the management behavior I've witnessed for years in the enterprise. We understand that we live in a world of cause and effect, but almost everyone is so busy poking at the effect that there's no energy left to discover and treat the cause.

It's a shame that so many of us workers continue to have so much passion for the work at hand and so little for everything else. It seems like it almost always comes down to this.

Respect, Guido.

- impeccably written emails detailing everything about every project and keeping everyone in the loop

- documenting every issue, question, and plan of action via email, letting nothing fall through the cracks

- status reports like clockwork

- precision on requirements and specs, spelling everything out, leaving nothing to chance

- a great attitude and team player (barf barf) in writing

Do these things and insist that others do (along with all you other dazzling work) and they'll have no excuses not to keep you when you decide to go remote. They'll already know you're a "professional".

Just quit.

  1. It's a job, not your life.
  2. It's a company, not a person.
  3. "Top Tier" means neither.
  4. If you were hit by a bus, they'd cry for 7 minutes and never think about you again.
  5. "My work is my reference." is my standard response to that request. It works. To those who matter.
  6. Moving on can skyrocket your growth when done properly. Listen to your gut.
  7. "I stagnate easily." is my standard response to "Why so many jobs?"
  8. You'll probably be surprised how underwhelmed they are.
  9. You'll probably be surprised how much energy you wasted over this.
  10. You'll definitely be glad it's over.

No one from work cares about you nearly as much as you care about your work. Don't make this so complicated.

You have personal relationships you'll miss and don't want to hurt. If that bothers you, quit over beer.

I never provide or look at anyone else's code before getting to know them for these and many other reasons, but mainly because a repository is in such a vacuum, without context or correlation to what the person really can do.

To paraphrase an old mentor: "Someone with a perfect repository is either faking it or has never taken enough chances."

Great comment of an instance.

The class:

"Letting <anything> ruin it for others is a management problem, not an <anything> problem."

I have rarely run into the "brilliant jerk" problem.

I have almost always run into the "incompetent manager" problem.

"Incompetent Managers in Engineering". Now there's an article I'd really like to read.

Maybe after you've had enough of working on so much others' shit, not much else matters.

How could something so horrible happen to so many so routinely? Any what can we techies do about it? I'm always searching for meaning in my work and I'm having trouble remembering anything I've worked on lately that's nearly as important as this issue.

Then I realized that the solution is already in the article:

In the course of his thirty-five-year career, Shafer has assumed control of more than three thousand wards and estates and trained a generation of guardians.

and

When Concetta Mormon, a wealthy woman who owned a Montessori school, became Shafer’s ward because she had aphasia, Shafer sold the school midyear, even though students were enrolled.

and

Parks and other private guardians appeared to gravitate toward patients who had considerable assets.

It's all about the money! They don't go after poor people.

How can we high achievers turn this into a business opportunity that's a win-win-win for everyone and put the bad guys out of business? It's almost like we need a watsi for senior citizens. Thoughts?