Hacker News Reader

Comment by bovermyer | Hacker News Reader

When I was in my twenties, I was part of the early "life coach blogger" culture.

Now that I'm almost in my forties, I realize everything I wrote back then was bullshit. Earnest, but bullshit nonetheless.

I'm much more cynical, but I'm also much more likely to just do what seems right and figure out the rest as I go. I don't read "best practices" or advice articles anymore.

This is not to say that there is nothing to be gained from such sources; just that the likelihood of it being useful or accurate given my particular context is small.

In this, my attitude is much closer to where it was in my teens and childhood, where I just had to figure everything out on my own.

View on HN

I’ve read a lot of time management/productivity books, and there seem to be only two things all of the authors agree on: write stuff down, and continuously tweak your system.

The latter is usually mentioned offhand in the preface, as the author wants to deliver a fait accompli instead of just some tips and tricks.

Can you elaborate on "write stuff down"?

Plan, write a log of work, write down your todos, keep track of what your doing and keep yourself accountable.

I keep an Excel control table. Every task assigned goes on that table with a project, type (report, code, algorithm design or integration work) and module (which part of the project needs an update). There is also a remark column which I one day intend to process with nlp. I also like to generate a pivot table at the end of each week to know which type or modules of work I'm neglecting. I've also got some conditional formatting to mark rows as red when I blow the deadline (red) or when I need to finish something by today (yellow). Has worked well for me when I was an engineer and I'm evaluating this work flow for an integrator (it's an official post for someone who makes sure that several teams deliver compatible outputs on time).

Broadly, use external storage (paper or a computer) to keep track of things that you don’t need to know right now so that that mental capacity is available for whatever you’re actually working on.

The one true path is that there are no one true paths and that the most successful people seem to have the best managed iterative learning cycles (and write stuff down).

To what extent do you suppose "continuously tweak your system" really means "show up"?

That is, could you substitute any other activity that requires you to actually pay attention and be present and get equal progress?

I think there may be a category theory of self improvement. The more I look at the things I've done to improve my situation from health to work to finances, the more they start to look similar (in a nutshell, it's not math, it's not psychology, but it might be both).

That’s a large part, but there’s also an aspect of kaizen to it. Everyone’s thoughts work a little bit differently, so the mechanisms that work best for me maybe don’t work quite as well for you. Regularly asking yourself “how can this be better” is the only way to maximize your own efficiency because nobody else is competent to answer the question.

Mastery is when you not only know the rules but also know which rules you can ignore in your particular situation.

"The Code is more what you call guidelines, than actual rules."

“By all means break the rules, and break them beautifully, deliberately and well. This is one of the ends for which they exist.”

― Robert Bringhurst, The Elements of Typographic Style

I started to see the same trend in technology hopping. New language's or frameworks are barely around long enough to develop long term maintainability best practices borne from experience, so everyone's blog posts are just well intentioned speculation.

You end up seeing enough contradicting information said absolutely that you realise no one is ever 100% right.

This extends to methodologies.

At this point am convinced that a competent team will complete the same project under formally waterfall, XP or Agile governance with only minor schedule differences.

I'm a huge fan of Alistair Cockburn's thinking on this point. He argues that people - and their characteristics - are a far greater driver of project success than methodology.

The argument is not a formal one, but I think still holds a lot of weight:

https://ameyakarve.wordpress.com/2012/07/22/characterizing-p...

I agree with this for the most part, though there are many false positives of “great teams” on paper who screw it all up purely because of a backwards methodology.

Methodology and people are not mutually exclusive. And it’s a lot harder to swap in and out people (though it may be necessary).

I too am quite skeptical, but I do try to find the "best practices" contents in areas where I am new. I find these articles often provide some insight from the perspective of someone who actually has experience (extra credit if he/she is part of a team), and even if I eventually change my practices as I learn more, I start down a good, if not perfect, path. In short, it speeds up my learning process.

I always try to keep in mind that having any strategy at all, even if it's not the actual best strategy, is usually good enough. So while yes, a lot of the advice you get is bullshit specifically, generally following some system is almost always better than not following any system at all.

This is also something I try to remember when making a tough decision; how substantial is the difference going to be, actually? Usually it's not anywhere near as substantial/irreversible as I thought.

I've stopped fighting a great many work battles for this same reason, as well.

Reply on news.ycombinator.com