tobym + advice   74

#gamedev 12 tips for making the best use of your time - macton
Some tips that have worked for some people, some of the time, for some common problems. YMMV.

In arbitrary order:

1. Help! I'm constantly distracted by email, IM, random things.

Block no-email time in your calendar. It's less complicated than it seems. Even just two hours a day could make a massive difference. Trust me, if it's that urgent, someone will figure out how to find you.

2. Consistency is the key

Each morning write down one thing you can accomplish that day that would make the day worth it. Then just focus on that one thing until it's done. Everything else is gravy that day. If you aren't almost done half-way through your day, it might be time to consider a new plan.

3. Practice makes better

Practice helps you get more efficient. Being more efficient gives you the extra space you need to become better. Dedicate no less than 30 minutes a day to one specific activity that you can do to improve your skill. It's your skills, your career, your profession. Your homework for yourself. Do it every day, no exceptions. Throw away the results each day; the point of practice is practice, not building something.

4. So. Many. Meetings.

Find out before meeting what specific questions the person that called it is trying to answer. See if you can answer those questions in advance. Then if you're lucky you can either individually decline or get the whole meeting canceled because all questions are already answered. At worst, you're better prepared.

5. Every goddamn thing is on fire! At the same time!

Triage. Someone utters the phrase "would be nice"? That item is cut. Anything you don't have extremely high level of confidence in, is cut. Basically anything that would not be an immediate catastrophe is cut. That's the easy stuff. After that, everything is still on fire and you still aren't going to be able to do it all. The only thing that matters here is that you admit it. Some of these patients are going to die. Pick some, live with that choice, and suggest people get comfortable with the others or find workarounds. That's the time to get creative.

6. How much is it worth?

Before you sit down to do something, decide how much it's worth. How much time could you spend doing this and it would still be worth it? Two days? Two years? Where is the line? How much would you personally pay someone to do this? With that in mind you can decide when to completely stop what you're doing if it's not going well and throw it out (if you have nothing useful) or use an earlier, but less awesome iteration (if you have something that at least works).

7. Seriously, you don't need to be involved in everything.

Are you afraid that someone is going to make a decision that affects you without consulting you for your opinion? Get over it. It will definitely happen. It's an absolute certainty. Expecting that everyone (or selfishly, just you) would be involved in every decision that could potentially impact you is... impractical. Everyone that you add to a conversation is going to make that decision making process more complicated. Getting the right and fewest people is a trick. Make a list of the decisions you absolutely, without question, need to be part of. Make sure people see that list. Make sure people know when to bring you in (and can infer when it's not as necessary.) Expect the same from others. If you don't know their list, ask them directly.

8. Where did the day go?

You get to the end of the day and feel like you didn't accomplish anything. That happens a lot. What's happening? Why do you feel so useless? Stop. First you probably just need some perspective. And second, it probably is true that you're not spending your time as wisely as you'd like. Everyone hates this exercise, but it's still a straightforward and valuable approach: For a week, track every minute of your day. Write down everything you do. Get a coffee? Write it down. Read an email? Write it down. Wander around and have a chat? Write it down. Account for every moment. Once you've done that as honestly as you can, you probably have some insights you can work with to actually answer the question of where your days are going.

9. Holding people up with lots of small things

You're getting to the urgent stuff. You're getting to the important stuff. But there are small things that people need (replies to emails, code reviews, whatever) that aren't particularly urgent or hugely important. Until they are. People have to bug you about it. And by then it's become urgent or important. Two useful tactics: (1) Don't read it twice. If you're taking time to read email, prepare to respond during that time. Anything you can possibly get an answer to, answer immediately. Don't "get back to it" if you can help it. And (2) keep a separate list of those little things that build up during the day, and just knock them all out at once before you end your day.

10. Brutally honest about your own progress

If you catch yourself thinking "I can make up the time" or some variation, stop. You can't. You're behind and you need to start thinking about (1) who needs to know; and (2) how you can adjust everything else to accommodate. Now, before it gets desperate. Once you've used 50% of the available time, if you're not 80% done, you are behind. And 80% done basically means you could walk away. It works, it's not your best work, but you could stop now. If you catch yourself saying "lots of stuff just came up and got in the way" or some variation of that, stop. This probably isn't the first time you've had to deal with fires and random things. In fact, while any individual item isn't predictable, I'd bet that the total amount of your time spent on unpredictable items is extremely predictable. Account for it.

11. Don't answer the same question three times

Have you answered the same question twice? It's probably safe to assume you will be asked again at some point. Either (1) document the answer so that you can point to documentation when you are asked (don't assume people will read it in advance and not ask though, that's ridiculous! No one will ever RTFM first); or (2) teach someone else the answer so they can answer the question in the future instead of you.

12. Trust the process

The fantasy: "Next time I'm going to do it sooner and better. I'm going to make all these amazing decisions way earlier, because it's such a mess when they are made late." The reality: That doesn't happen. There are too many variables changing at the same time. The ideal, theoretical approach will remain both. For any given issue, ask "What are the absolute minimum answers I need before being able to reasonably solve this problem?" Write them down. Put aside the problem until those answers are available. Spinning your wheels on problems you can't solve yet will waste a lot of your time. See also: Preproduction.
productivity  advice 
7 weeks ago by tobym
The traits I value most in the people I work with... - macton
Be a champion for quality
Be a champion for efficiency
Have an insatiable curiosity
Have a point of view
Value good communication
Value introspection and self-review
Be pro-active
Be fearless in the face of hard problems
Value performance
Value simplicity
Be responsible with expectations
Be responsible with time and resources
Bring more value than cost
Give and receive feedback well
Be a leader
leadership  inspiration  advice  management 
7 weeks ago by tobym
Alexandrian Form (of documention)
The AlexandrianForm of patterns has the following sections:

The name of the pattern. Alexander's names can name the thing created by the pattern, the process of creating it, or some attribute of the solution.
One sentence per pattern that can be expected to precede this one.
Problem statement
One or two sentences that summarize the problem solved by the pattern.
Anywhere from 4 to 40 paragraphs that illuminate the system of forces resolved by the pattern.
One or two sentences that tell you what to do to solve the problem.
A picture or two, hand sketched or photographed, that illustrate the pattern (and sometimes the lack of the pattern).
One sentence per pattern that can be expected to follow this one.
documentation  howto  patterns  architecture  advice 
8 weeks ago by tobym
Startup advice from mixpanel guy
The best way to control your own destiny as a company is often to make just enough revenue that you can always dial down expenses fast enough (<= 6 mo) to be break even if you get shitty terms or get into bad circumstances.
startup  advice  business 
july 2018 by tobym
Corporate life
models are for engineers, summaries are for managers, and recommendations are for executives
management  planning  advice  from notes
june 2018 by tobym
engineering leadership
the “good, fast, cheap…pick 2” for engineering leadership

* lead strategy
* manage teams
* write code
(pick 2)
engineering  leadership  management  advice  from notes
june 2018 by tobym
Always start with a stupid model, no exceptions. – Insight Data
Linear Regression. A solid first approach for predicting continuous values (prices, age, …) from a set of features.

Logistic Regression. When trying to classify structured data or natural language, logistic regressions will usually give you quick, solid results.

Gradient Boosted Trees. A Kaggle classic! For time series predictions and general structured data, it is hard to beat Gradient Boosted Trees. While slightly harder to interpret than other baselines, they usually perform very well.

Simple Convolutional Architecture. Fine tuning VGG or re-training some variant of a U-net is usually a great start for most image classification, detection, or segmentation problems.
ai  ml  advice 
march 2018 by tobym
How the Godfather of Cyberpunk would write software | Lobsters
This reminds me a bit of a technique Joe Armstrong mentioned, maybe in an in-person conversation at a conference or maybe more publically, I forget. He said that he will throw away code that takes him more than one day to write, and either start over the next day or do something more important. His justification was that if it takes longer, the approach is probably shit. At the time, I thought it was a pretty extreme approach, and just made a mental note of it and moved on.

After spending the last year+ making a reasonably well tested database, I’ve caught myself having taken on this approach myself, arriving at it after an endless series of devastatingly complicated bugs that have deeply humbled me. It was quite a surprise when I realized it was exactly what Joe had mentioned, that I didn’t really believe was an effective strategy at the time.

Why do this? For me, it keeps the complexity manageable. If I can’t keep the whole thing in my head when I’m creating it in one shot, there’s very little chance I’ll be able to debug an issue in it in under one or two days. I will create far more bugs when I can’t wield the model of it easily in my mind.

How long do you want to spend debugging an issue in a system? Combine this approach with bwk’s “debugging is twice as hard as writing a program in the first place” rule of thumb and throw the whole thing away when you get to 1/2 of your desired debugging budget!
programming  tips  advice 
march 2018 by tobym
10 Rules for Students, Teachers, and Life by John Cage and Sister Corita Kent – Brain Pickings
RULE ONE: Find a place you trust, and then try trusting it for awhile.

RULE TWO: General duties of a student — pull everything out of your teacher; pull everything out of your fellow students.

RULE THREE: General duties of a teacher — pull everything out of your students.

RULE FOUR: Consider everything an experiment.

RULE FIVE: Be self-disciplined — this means finding someone wise or smart and choosing to follow them. To be disciplined is to follow in a good way. To be self-disciplined is to follow in a better way.

RULE SIX: Nothing is a mistake. There’s no win and no fail, there’s only make.

RULE SEVEN: The only rule is work. If you work it will lead to something. It’s the people who do all of the work all of the time who eventually catch on to things.

RULE EIGHT: Don’t try to create and analyze at the same time. They’re different processes.

RULE NINE: Be happy whenever you can manage it. Enjoy yourself. It’s lighter than you think.

RULE TEN: “We’re breaking all the rules. Even our own rules. And how do we do that? By leaving plenty of room for X quantities.” (John Cage)

HINTS: Always be around. Come or go to everything. Always go to classes. Read anything you can get your hands on. Look at movies carefully, often. Save everything — it might come in handy later.
life  advice  inspiration  learning 
february 2018 by tobym
Google's Eric Schmidt says these are the most important traits for job candidates | World Economic Forum
ultimately two simple things matter more than anything in a job candidate, and they're the same for a startup or a massive corporation.

They are persistence and curiosity.
google  advice  leadership  hiring 
july 2017 by tobym
The Pragmatic Bookshelf | List of Tips
Obvious good dev tips, but good reference.
programming  coding  dev  tips  advice 
august 2016 by tobym
Apprenticeship Patterns
Apprenticeship Patterns

Guidance for the Aspiring Software Craftsman
learning  programming  book  education  advice  philosophy 
may 2016 by tobym
What Makes an Effective Executive
Reprint: R0406C
An effective executive does not need to be a leader in the typical sense of the word. Peter Drucker, the author of more than two dozen HBR…
leadership  advice  management  from instapaper
december 2015 by tobym
Core job descriptions for system administrators. Useful for determining the level of responsibility for juniors to directors to CIOs.
hiring  management  advice 
november 2015 by tobym
How to Charge for your Open Source
Nice, simple model. AGPL license by default with MIT commercial license available for purchase. Sell via Plasso/FastSpring/Wufoo, charge hourly rate for small projects or whatever is appropriate for larger projects. Subscription or one time per version is up to you, but prefer subscription because usually the work is on-going.
opensource  business  advice 
november 2015 by tobym
How to Design a Better Pitch Deck · The Macro
Good general presentation tips, not specific to pitch decks.
business  presentation  advice  startups 
november 2015 by tobym
scalac compiler options
Good set of conservative options for scalac.
scala  advice 
january 2015 by tobym

Copy this bookmark: