macton.ninja



The traits I value most in the people I work with...

posted Dec 7, 2016, 6:42 PM by Mike Acton   [ updated Mar 31, 2017, 10:08 AM ]

An unordered list of the traits I value most in the people I work with generally and on my team more specifically.
  1. Be a champion for quality
  2. Be a champion for efficiency
  3. Have an insatiable curiosity
  4. Have a point of view
  5. Value good communication
  6. Value introspection and self-review
  7. Be pro-active
  8. Be fearless in the face of hard problems
  9. Value performance
  10. Value simplicity
  11. Be responsible with expectations
  12. Be responsible with time and resources
  13. Bring more value than cost
  14. Give and receive feedback well
  15. Be a leader

On why DoD isn't a modelling approach at all

posted Aug 22, 2016, 3:13 PM by Mike Acton   [ updated Aug 22, 2016, 3:27 PM ]

Q: Isn't Data-Oriented Design just dataflow programming?

Or: Why DoD isn't a modelling approach at all.

I'll quote an exchange with Christer Ericson's answer (with permission) on this subject:

No, not dataflow programming.

Dataflow programming, as well as OOD for that matter, is a modelling approach, and specifically for dataflow programming, by expressing data connectivity as a graph.

While neither me, nor Mike [Acton], nor Noel [Llopis] has ever provided an “official definition” of DOD (nor have we really been interested in doing so, nor would we necessarily 100% agree on one), I would argue that DOD is not a modelling approach, in fact it’s the opposite thereof.

As Mike has eloquently pointed out elsewhere, computation is a transformation of data from one form into another. DOD is a methodology (or just a way of thinking) where we focus on streamlining that transformation by focusing on the input and output data, and making changes to the formats to make the transformation “as light” as possible. (Here there are two definitions of “light.” Mike would probably say that “light” means efficient in terms of compute cycles. I would probably say “light” means in terms of code complexity. They’re obviously related/connected. The truth might be in between.)

I say this is the opposite of a modelling approach, because modelling implies that you are abstracting or not dealing with the actual data, but in DOD we do the opposite, we focus on the actual data, to such a degree that we redefine its actual layout to serve the transformation.

DOD is, in essence, anti-abstraction (and therefore not-modelling).

In practice, we find a balance between the anti-abstraction of pure DOD and code architecture component needs.



#gamedev 12 tips for making the best use of your time

posted Feb 23, 2016, 6:20 PM by Mike Acton

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.


How do I install chroot crouton/ubuntu on chromebook/acer/x64?

posted May 2, 2015, 1:01 PM by Mike Acton   [ updated Feb 21, 2017, 12:26 AM ]

My notes...

Install via crouton
  • See: https://github.com/dnschneid/crouton
  • List available releases: crouton -r list
  • crouton -r <release name> -t cli-extra
(chroot) Install common stuff
  • sudo apt-get update
  • sudo apt-get install build-essential binutils elfutils git gperf subversion unzip zip nodejs clang yasm
Install SBCL
  • Don't: apt-get install sbcl
  • Download from: http://www.sbcl.org/platform-table.html
  • sudo sh install.sh
  • Install quicklisp: https://www.quicklisp.org/beta/
Install user .bashrc
  • This is mine. There's nothing special about the setup here. If you already have one you like, use yours without any modification.
  • $ cd ~
  • $ wget https://raw.github.com/macton/arch-linux-install-notes/master/common/.bashrc --no-check-certificate
Name the chroot
  • I don't bother with hostname shenanigans. Just fix up the display. Unique name helpful when referencing ssh keys, etc.
  • Pick a name: http://www.computernamer.com/
  • Change host display in .bashrc "\h" to name.
Config ssh keys for github See: https://help.github.com/articles/generating-ssh-keys
  • $ ssh-keygen -t rsa -C "your_email@youremail.com"
  • $ cat ~/.ssh/id_rsa.pub
  • Copy and paste to https://github.com/settings/ssh
Config git See: http://git-scm.com/book/en/Customizing-Git-Git-Configuration
  • $ git config --global user.name "John Doe"
  • $ git config --global user.email johndoe@example.com
  • $ git config --global push.default matching
  • git config --global url.ssh://git@github.com/.insteadOf https://github.com/

*.ninja

posted Jun 5, 2014, 11:28 PM by Mike Acton   [ updated Jun 5, 2014, 11:28 PM ]

*.ninja TLD are available now. How did I not know this?

— Mike Acton (@mike_acton) June 6, 2014

1-5 of 5