Edit to add that the course was “Time Management Fundamentals (2016)” by Dave Crenshaw. I completed it on LinkedIn learning. For those of you who’d like to give it a try, my advice is: do all the exercises. You won’t get the full value out of the course unless you actively incorporate the whole routine into your workflow. There’s a learning curve, but it’s absolutely worth it. Also be warned that the presenter’s personality is a little off-putting (to me, anyway), but he absolutely knows what he’s talking about, so listen to him.
The "time management tips" one is a kind agglomeration of his advice on managing your time, your relationships, your reports, etc., and is a good follow-up. He has a course on having productive meetings, as well, which is well worth the time. It may make you hate meetings at your work, though XD.
Honestly his courses provided a lot of relief and validation to me, as well as hope for a future working in companies. I can't recommend them enough.
I might watch it ... later :p
The course doesn't offer anything novel - for example it has elements of Getting Things Done. But it's presented in a more accessible way that resonates with me. It also focuses on making good habits, something I already discovered in another book recommended on HN, Tiny Habits.
Thanks for the recommendation. I really appreciate it.
You rarely, if ever, need Leetcode. What you need is to understand deeply what you should be building so you don’t waste everyone’s time!
As compared to places like tesla/shopify/etc where the Steve Jobs quote rules the roost:
It doesn't make sense to hire smart people and tell them what to do. We hire smart people so they can tell us what to do.After a couple of years and several such reporting options someone asked, "Can't we just generate a spreadsheet and then your business analysts can do whatever reports they want from that?" and the customer responded, "You can do that?! That would be so much easier for us."
Imagine the weeks or even months of human life (both implementing but also using the less efficient reports) that could have been saved if the right solution had been implemented from the start.
That's literally time taken out of someone's life that they could have used to be with family or whatever they wanted instead of transcribing ridiculous reports.
(Of course, those reports were probably only generated to be looked at once in some recurring management meeting, only for the executives to feel good about having seen data. I don't think the reports were ever used to support any decision.
This means the entire reporting theatre was completely bullshit and the customer could have paid the business analysts to sip drinks on the beach instead with no loss of productivity. But that's just my cynical view.)
Only if the product is run by one or two people who give each other that much time off. *Much* more likely, this work not commissioned by the client, leaving space for other work to be done.
This "automation will lead to more free time" is a utter utter myth, because those with the power to pay staff will just sell their staff's time+skills to someone else/some other problem.
(There's a tiny chance the void would be filled with useful work, and that's also a good outcome in my book.)
These are unlikely to be technical issues, and more people/process issues. SPAs are popular because they optimsie for developer productivity (so arguably the opposite). Others have talked about them, but examples like focusing on the wrong problems to solve (if you're a startup making a video game, do you really need to build your own chat app? [0])
How much of that waste would you attribute to 1x programmers and how much would you attribute to 0x managers?
And I mean, who is responsible for curating those 1x engineers in the first place?
Failed projects are inevitable though, even if you do everything well. Good teams don’t look for people to blame, which results in no one sticking their neck out to advocate for stuff. Instead they look to learn from each experience and hone their processes.
What are you referring to?
As an aside, from a developers perspective, all of the work is clearly valuable, I mean they got paid 300k+. But from a true definition of value perspective, the change increment is just not valuable to the users as evidenced by the lack of use.
Value: Reliable fulfillment of needsMidwestern US salary caps are more like $90k-$150k.
"There is nothing so useless as doing efficiently that which should not be done at all."
Damned, I had to search for the author and... it's also from Peter Drucker !
The proof is that a good coder spends about 10x as long thinking about it before actually committing any code. In a sentence: Be able to visualize the problem in your head first. The actual code, if it's elegant and succinct, is incidental.
This seems antithetical to the post above yours. Or at least how I'm reading it. In bigger tech co's this looks a lot like massive design documents with a dozen reviewers, all giving enormous amounts of time and thought to the idea in the pursuit of "building it right". Design processes that can take weeks or months for what is otherwise an MVP.
Obviously you have to take security into large consideration when doing things like this - but this is what qa/sandbox environments are for.
I'm a bit of a rarity in the modern world (and here in the corporate space that is HN), in that I'm the sole programmer on a bunch of large software projects in production that I also maintain and sysadmin 24/7. The only meetings needed are to understand what the clients want and bitch at them that what they want makes no sense, until they start making sense, and then trust me to build it. If something comes up from a design perspective that I think could go one of several ways, I usually have that thought in the shower and mumble to myself for awhile before framing it in terms they would understand as a series of yes/no choices.
This is generally way more efficient than hiring a team, and I know, because I've tried to hire teams to do it. There's a limit to what one coder like me can do, but it's a lot higher than what 4 people bickering can do. I'd say it's around what 8 bickering people can do.
Design and defense of design, though, is not just about ego. Not if it's done properly. The best design/code people will come to you and say this is why this is the only way to do X and lay out the chain of logic that led them to that conclusion. That's not because they'll be personally hurt if you don't go that direction; it's that they're annoyed they'll have to do extra work to make an inferior product if you don't take their advice. Promote those people.
I'll say. It does not sound like you'd be very fun to work with, as a teammate or a stakeholder.
If you saw what I write you'd say I was a 20x coder, but that's just from a youngin's perspective. I've been writing code since 1988. The basic value proposition for my clients is that they know I'll die at some point, but it's way cheaper and more efficient to pay one guy they know will get it done, and take the risk they'll have to scramble for someone else in less than 10 years (at which point they'll likely have to rewrite anyway). Also, the shit I write mostly maintains itself. I'm proud to say that my software in 24/7 production has had no actual crashes in years other than the occasional forced server upgrade. If I died, it would take awhile to notice if they didn't keep asking me for new features.
You can have bigger changes as proof of concept first, but select, properly design and launch the most important one.
At one time he was scared of the problem of scheduling the fleet. Yup, if describe the problem in complicated terms, then the scheduling problem gets wildly complicated, e.g., in NP Complete, etc. -- could have a big team working months on just the first version. But he needed answers right away and, to satisfy concerns of some investors on the Board, needed the answers also to apply to the whole, planned company (eventually it grew to something much bigger than the initial plans).
I was in a meeting looking for a solution with several people, and it was all confused. Finally I just announced that I'd solve it.
I was teaching computer science at Georgetown and had 6 weeks to go to the end of the semester. So, I wanted to be done in six weeks. How'd I do that? Sure, just concentrated on what the business actually needed and threw out the rest. So, in six weeks had the software putting out nice schedules.
Our two representatives of BoD member General Dynamics and major investor evaluated the schedule and announced "It's a little tight in a few places but it's flyable.". The BoD was thrilled.
At one point Smith stated that my work "solved the most important problem" facing the company. The 10X, maybe 1000X, difference was essentially just in delivering what the business needed and dropping the rest.
"Landing the plane" as they sometimes say.
A closely related skill is the ability to cut through all the abstractions and interfaces to get to the root cause of what is broken or needs changed. A technical and organizational debt buster if you will.