"Maintain context outside of your head at all times"
Yes. I currently keep a text document, "NOTES.md", open for whatever project I'm working on.
This isn't a bug list; it's just things that I'll need to come back to and deal with. If
there's something that has to be dealt with, and it's not in comments in the code, it goes here.
This is in the code directory and is checked in with Git, but it's just for my own use.
Some excerpts for a large C++ program:
Added logging to viewer. Turn off FSEnableLogThrottle debug switch
when in use to catch all log messages.
Logged a short road trip and a short boat trip. Huge Z velocity noise on road, low noise on water.
2020-03-24
Trying various forms of filtering. Current approach:
- Low-pass filter linear velocity and angular velocity.
- Difference with instantaneous velocity and angular velocity
- Get magnitudes of differences.
- Time limit for each is allowed error / magnitude of difference
- Use lowest time limit to limit extrapolation time
Simple analysis of the data indicates this might work
Problems:
- Filtering data with varying time deltas needs work.
Test uses the assumption that updates come in at a rougly uniform rate.
- Need to convert linear velocity to object coords before filtering so smooth turns work.
2020-03-31
Adding files to Firestorm:
Add .cpp and .h files to appropriate sections of
indra/newview/CMakeLists.txt
New files go in
indra/newview
Then ?
Run autobuild again?
Script
sh installnewfiles.sh
copies the new files to the newview directory.
Our version is maintained with git in the firestorm-mods repository
2020-04-02
Extrapolator is running. Results not too good:
- Seems to be be overrunning extrapolation limit. Not sure.
- Extrapolation limit is calculated before the last object updates have arrived.
So last-second changes in the velocity are not caught.
- Working. Good tuning values are filter, 10 secs,
angle err, 20 degrees, position error, 0.25m.
If you are working with others, I've found full-time pair programming shops are extremely resilient against interruptions. Sometimes the person who is not driving may explicitly maintain notes on the state of the task, but even besides this, any lost state information from an interruption is far easier to recover.
>I think the style in which I practiced my craft for the first 15 years of my career was much the same as every other enthusiastic developer: you put a ton of hours in. 12-16+ hour days, evening and weekend coding marathons, pizza in the keyboard, crunch times, 3am debugging sessions where you just can’t go to bed because you can feel the source of that bug just beyond your fingertips, dammit, desperate last-minute sprints to deadlines where you manage to slot that last piece in, Jack Bauer-like, just before the world goes to hell.
Uhh... does anyone other than maybe 1 in 100 developers actually do this? I think that many more than 1 in 100 developers are enthusiastic... but I doubt, whether they are enthusiastic or not, that significantly more than 1 in 100 developers or so act like the above. If I'm going to work 12-16+ hour days, I'd better either be in love with the company or have a good reason to expect that I could cash out and be rich as fuck at some point.
Some people do do this ... for the first few years, until they burn out or decide they want a relationship.
The most productive person I've ever met wrote an H265 decoder by himself in three months of working four-day weeks so he could spend time with his family.
> Some people do do this ... for the first few years, until they burn out or decide they want a relationship.
I still do it. I'm 34 and currently with my second live-in girlfriend. The first one didn't leave me due to programming; I just decided to go for a younger model. I'm not trying to brag but rather dispel the myth that you need to stop programming to have a relationship. My girlfriends have always known what is important in my life: me, my computer, my car, my bicycles, then them. Instead of relying on being the most important thing in my life, I encourage them to the be the most important thing in their own lives. It's a far healthier relationship and part of a Stoic lifestyle which I find to be the true path to happiness.
It's real in the sense that it's honest, yes. Do you doubt that? I see it's downvoted despite containing no offensive language and merely being an honest account of my life. I wonder why that is. At least I can say I'm not just spouting stuff that makes the echo chamber happy. I love programming and I love machines. Designing and building them gives me a purpose in life. I also have a primitive desire to mate. Does any of that offend you?
I'd think people are offended to know someone - even on a message board - who is happy to speak so publicly and callously about their intimate partners.
It makes this place seem glum and regressive. It's the opposite path to achievement described in the article.
It expresses at least one idea that people find morally reprehensible. It being honest is not a redeeming quality.
Additionally, looking through your comment history, I feel your comments are really written by a human, but they do have a very eerie similarity to comments written by GPT2 bots.
I did not say your comment _is_ morally reprehensible, only that it’s widely and commonly believed to be morally reprehensible by many people. I decline to state my personal normative view about it.
That part is when you refer to having a new relationship partner as getting “a younger model.”
I do not have any trouble believing you exist and I believe people like you are reasonably widespread.
I only meant to indicate the cadence and style of your written comments has a great degree of similarity with the text generated by GPT2 bots.
It's fascinating but also quite scary that you would probably believe me if I told you I was a bot. It seems that those bots are so good now that if you read some human output with the idea that it might be a bot (because e.g. someone asked if it's "real") that you can't actually tell. That provides a whole new way for echo chambers to extinguish dissenting views.
I agree with your comment for sure. But I also think it’s interesting that your natural style of communication is so readily emulated by bots. I don’t think it’s true of all people generally. Some people are just more bot-like in their internal processes I think.
I'm pretty autistic. In a way I am a bot who has learned to be more "human" to get what I want in life. Naturally I'm a complete recluse, but I found that didn't make me happy.
To decode H265? I don't know why this is such a ludicrous proposition to you?
Less jokingly, it was a side output of his bigger project to automatically parse the H265 spec using a tool called O-Meta. This made it surprisingly easy to write a minimal frontend to produce an (unoptimised but working) decoder in C, Javascript, etc. The actual product became https://www.broadcom.com/products/embedded-and-networking-pr... : a codec test suite. Incredibly valuable for those companies making hardware decoders. Similar in structure to an input "fuzzer". Found a number of bugs in the official reference decoder's C code.
Well, yes, people do, and the trick is to love your work and your company. I was definitely doing so when I was doing my own startup.
I've worked before in a place that was mostly people who just show up for a 9 to 5 (or often more like a 10 to 4). It just felt super-depressing to me to look up around at 6pm and the whole floor is completely empty. Didn't last long there, but I guess it was a nice sabbatical.
These days I work closer to 10-12, but if I'm on a good pace in a groove, or someone needs help with an urgent issue, or it's just some self-imposed mental deadline, that can easily stretch the day to past midnight. I would say most of my peers work similarly.
This is clearly an exaggeration, and I think more of us can relate than we're letting on. Programming, when you've never done it before, is hard! If you're not willing to put in the hours at least a couple of times in your life, you're probably not going to ever really "get it". At least that was my experience. I never worked like this regularly, but I've had several times where I stayed up way later than I planned because I "just wanted to figure it out". And without that, I don't think I ever would have become a decent programmer.
I think this is the picture that a lot of junior developers miss. Sure, that 12-16 hour marathon session sounds horrible and unsustainable in many ways, but it's also the fastest way to achieve mastery (or realization, burnout and career change). There are obviously a ton of other variables involved, but time is the most important investment you can make. Ideally, you are also working with practical tools and compelling business requirements on a regular basis.
Assuming you survive the first 2-3 years of hell and approach that level of master, you are now in a position to back off your time commitment substantially because every second you spend working as a master is like a lifetime to an apprentice. Gains in mastery in this craft are NOT linear in my experience. It's more like a polynomial or exponential curve.
I also think time spent playing with abstractions in isolation from larger projects is also key to obtaining mastery. Much like trying to master a difficult piano concerto. You can't just play it from the top every time or you'd go insane. If you want to find the smartest guy in the room at a Microsoft shop, go look in everyone's users/[username]/source/repos path. Whoever has the highest numbered ConsoleApp wins the prize. Again, no substitute for practice and breaking things. Remember, there are zero consequences if you write shitty code and its still contained to your local machine. You can just type git reset --hard and go to lunch like nothing happened.
I agree... I've never ever seen anyone actually act like this. Even the most fanatical of my friends in university would never ever pull a 12h day by their own volition (mostly because they were all working full time jobs while still in college, so any free time you get is really really welcome).
I also don't think it's productive or good for your product. As a side thing I paint, I've studied art and illustration since I was 14 and the one thing you learn as a pro in that industry is to never, ever finish a painting in one sitting. It's easy to obsess and lose yourself in the details and completely miss the glaring errors, and these you can find only by stepping away and coming back with a fresh set of eyes. And this is just as true for programming.
Weird because I've seen loads of people act like this. It's very common among uni students studying almost any subject from my experience. I guess you associated with different people than I did.
I don't think it's a good idea or healthy but it definitely happens, especially at universities and startups. I used to do it on client projects too until I wised up. Though looking back on my code from back then I still achieved some pretty crazy stuff in that time. Pushing the boundaries of what I was capable of. There is an upside to being completely immersed even though I wouldn't do it these days because I value my health.
You can easily get half a CS department out to a hackathon to spend 36 hours straight at it. Not sure how long it lasts after graduation, but students can certainly behave like this.
The good ones do. You know the guy at work who seemingly knows everything? He did it. He probably still does from time to time. I did it when I was a student and working on free software. If the code is proprietary I am more strict about how much of my time is available.
The "power of breaks" really resonated. I, too, have learned that sitting at the computer is often the worst way of solving a coding problem.
I go for walks, or a run if I'm in the mood. No music. Just my brain and fresh air. It's about 95% certain that I'll come up with a solution to the problem while walking. Often I have to turn around and head straight back to the desk to start working on the solution. But I try to resist this, as I often come up with clarifications to the solution if I continue walking.
It's like my brain doesn't work properly unless my legs are moving.
Day to day work at at $largetechco requires such an enormous amount of context that even a simple task can cause my working memory to overflow, triggering my “this must be fixed, too complex” instinct, and paralyzing my ability to work for long stretches of time.
I find that I have to make a practice of ignoring my refactor instincts, because there usually just isn’t anything I can do.
Externalized context definitely helps, but 1 year in, I’m finding my brain has not adapted to this reality.
I use playgrounds and design documents to do most of my thinking because I simply cannot reason about the real application without my head exploding.
This has improved my thinking tremendously, as I was never someone capable of outlining thoughts before coding them. I still can’t do that, but when I encounter a challenge, I can draw up the simplest possible version of it in a playground, write a document about it, discuss with stakeholders, formulate a plan, then return to the real code where I can put my full focus on managing the background complexity, having already worked out the feature complexity elsewhere.
All of this is a huge part of the reason I love TDD. It's a checklist, and I've always got my next item, and my working state is by and large in the code. I can even code while VERY distracted (meetings, cough cough) and succeed (albeit slowly). It can help with the tangential issues; maybe I whip out a (failing) test, or maybe I just mantra "only fix this one test".
These are all great points in favour of TDD. They're a ratchet on your code that lets you crank it out in small increments without losing much progress.
I feel like this only helps with distractions and interruptions, though, if you're doing routine work that you already fully understand and can code 'off the top of your head'. Admittedly this is the entirety of many software jobs and the bulk of even the most challenging, but there's still sometimes a need for time to think unimpeded.
More or less the case here; wrote this project, now refactoring and adding tests. Not every part of it could be done while 'distracted'.
Good testing still helps with distractions because good testing enforces a code style that's very bite-sized; so if your 'tasks' are 20-40m, you can fit a lot of distractions. Also, each task (generally) by virtue of being so small takes up less mental RAM, so you don't have to page out as much when a distraction happens.
Also makes it easy to work "around" the hard part, and come back to it when you know you'll have that uninterrupted time. Or late that night when inspiration strikes and now it's easy :)
The hard / complex part is (first) parsing parts of a Slack conversation to the do the AI part, and (second) the Slack interactive messages, which get weird when you try to use them as a form.
a lot of just "if these messages happen in this order, this correct thing still happens", where the difference between different message types is, well, not minimal, but simple and straightforward.
This has definitely led to waaay to much copy pasta, but it's well encapsulated within the test fixtures.
TDD is great but if you are coding in a meeting... you should walk out. Let them know you are not needed for that meeting, it makes the whole company more efficient.
Sometimes it's more efficient to be in that meeting, and half-listening, rather than dealing with the fallout from bad decisions made without your ("wait, WHAT did you say?!") input.
On the other hand, it sucks being a person who is saying something in a meeting and then get interrupted because someone misheard something or didn't understand the context. Or when you ask a question to a person who is attending the meeting but they need you to repeat what you were saying because they weren't paying attention.
Agree, but furthermore, it's not only tests that allow you to keep context outside your head, but also compiler errors. On complex tasks for example, calling a method that hasn't been defined yet I can offload a subtask from my head because I know for sure the compiler will remind me to implement it later if I forget. Even more explicitly, mid task my c++ can be full of #error directives each with a little note for something to be fixed at that location before I even think about running anything.
Or, for that matter, if an entire stack of methods needs modifying to accept some new data type. All you have to do is modify one of them and the compiler won't let you run until you've done the rest.
Or modify the type definition and everything using it has to change. If you want to force check every usage, rename the type.
Not that I have anything against tests either, these are all just strategies for keeping a record of context.
I can see that. I definitely prefer my code to run even while broken, since I find it makes it easier (overall) to write - particularly when I don't have great docs for the data I'm getting from web hooks (I'm looking at you, Slack Actions), where it's useful to just pop into an in-situ REPL and poke around.
Although - waaay back in the day, I was very gung-ho about using C++ template shenanigans to enforce code correctness at compile time.
It depends what you're working I guess. I can see where you're coming from with web hooks; in the examples above it was more of a 'pure' algorithm module and much more self contained.
Haha, yes I overdid templates for this once too :)
I know you're serious, but if taken in good humor, this almost sounds like Dilbert's response to the interview question of what do you do badly. He gets nervous and says something like "I work so hard that I forget human hygeine and start to rot in my cube" or something along those lines. I've been up against some rough deadlines where that comic really came to mind :).
I know it's difficult, but do take care of yourself. I'm not sure where you live, but we prioritize work over life too much in many places (America, Japan, probably several others).
A healthy job in my opinion allows you to make enough money to not worry about your finances too much and enough time to enjoy the truly important things in life (family, friends, excercise, hobbies).
Everyone is different though and some people seem to really enjoy the stress of a high profile position (Ex: Musk) and many scientists that live to work. To each his own.
If you're feeling burned out, consider trying a new job. If you're in Silicon Valley, you can likely find a good IT job in much of America that pays well in a probably much cheaper area and that allows you more time to pursue a better work life balance. Personally, everything changed for me when I became a Father. I still love my job and put in a lot of hours, but I take time to spend with my family too. Don't feel guilty about it.
This guy's strongman "I've got news for you" philosophy is productivity porn. I do like the idea of the focus crown if you've got kids though, that's a good one.
The current demise of offices has done wonders for engineer productivity.
One of the problems is that it really requires that people think a little harder and actually write things down, rather than just blundering through things in real-time.
Oh my, I empathize a lot with the author. In january, long periods of sitting brought me a slip of the L5-S1 disc, and now I have to exercise every hour or so in the office for several minutes to be able to walk home with manageable amounts of pain at the end of the day.
It takes a surprising amount of willpower to stick to the exercise schedule. Call of the zone is alluring.
In case anyone here is in a similar situation and has any tips, please share ...
I was in an accident that resulted in the same L5-S1 area being injured, and spent several months recovering. Honestly, the thing that got me back on track was losing weight (I weighed around 220-230 at the time, and dropped to 180-190 and stayed there for several years). The pain periodically recurred, but nothing like the initial period. I took up walking, which turned into running (I played rec soccer, but that was the extent of my exercise prior to the accident). That may be out of reach depending on the extent of your issues (or other physical issues), but cycling, swimming, and rowing are great alternatives. I later took up BJJ, wrestling, and a conditioning course (meant to help with endurance in those other two). That did a ton to eliminate the pain. I learned what I couldn't do in BJJ and wrestling because of my back, but the gym I was at was great (a lot of 30+ participants, and a fair number over 40 and even 50) so I just partnered with people who understood my issues and we worked around it.
The main thing for me, with getting into running, was that I did it 3 days a week and it was in the US south, so I was able to go out almost all year. There were a couple ponds I'd run by so it was a great way to get out of the work zone and clear my head. When I started having knee problems I'd take my bike to the same area and make three laps (15k) a few times a week (low traffic, only had one near-accident when an asshole passed me while I was about to make a left turn).
I've moved, the weather was bad, and I didn't have access to a gym (and now I don't have access to a gym) so the weight started coming back and so did the back pain. I've got the bike fixed up now and the weather is better, so once I find some good routes here (I hate riding on roads with lots of traffic) I hope to shed this weight and get back on track.
I'm knowledgeable about upper back/neck problems and stretches, and do them for 4 minutes daily. I'll prolly do a youtube video on it.
Since you're a lower back case, I'd say learn all you can. Find a talented Palmer graduate. Research if leg raises are right for you, or sitting on a ball. Get and stay thin.
If you're in the Bay Area, go to Walkrite Shoes and get expert orthopedic insoles to stabilize your hips:
Unfortunately the real way to be an "interruptible programmer" is
a) be self-employed, i.e. be your own boss
b) have the kind of good work hygiene
This advice is worthless for 95% of programmers contending with interruptions, which are urgent (or putatively urgent) things from the people who pay us and cannot be ignored.
I read this back in the day, added some tool which bugged me every 30 minutes and remember enjoying it.
Not sure how I didn't carry it forward onto my subsequent computer, but have definitely pondered re-instituting over the years. Thanks for the re-share of the original justification!
I honestly don't know if this is because I'm dumb or I'm smart, or maybe the work context I developed in, but personally interruptions don't really screw up my flow much. The only time it really causes me to lose focus is if the interruption has a high emotional reaction.
I don't like interrupting others but at some point I wonder if some just don't do anything if they're not in "flow". I think it's important to be able to make progress when you're not in a flow state. Its a skill.
I find that I can tolerate distractions like getting up to get a cup of coffee or stretch or do a few push-ups without much issue. I am able to maintain complex state and jump back into the flow. Maybe this is just a young brain thing and will go way, but in any case, this advice seems to be more tuned to those sorts of distractions. What happens in an office is entirely different. Your working memory is finite and social interactions are complex. Moreover, most people become personally offended (whether they will admit it or not) if you do not appear to be paying full attention. This was a particularly bad case but I once had a boss who would become visibly angry if you even stopped to write some notes when he showed up to interrupt you. Many of these interruptions are totally irrelevant too. Your boss does not need to stop by 4 times a day to get a detailed progress report. Your chatty coworker does not need to talk about his weekend at the lake. It's perfectly natural to feel some annoyance in a situation like this and it seems kind of absurd and subservient to me to ask devs to bend over backwards to accommodate the personality flaws of their bosses and coworkers. Sure, you shouldn't let this annoyance derail you, but that doesn't mean you also shouldn't tell your chatty coworker to shut up occasionally. Okay, maybe you shouldn't be so rude about it, but you need to set healthy boundaries and be allowed to block off time for the work you need to do. If you aren't, you are probably working for a shitty boss or organization. No amount of distraction management is going to help you there.
Beyond that, I think that there is a limit to the complexity of problems that can be tackled without periods of extreme focus. Some problem domains are full of deep and irreducible complexity. It's probably true that we often mistake accidental complexity for irreducible complexity or fail to break down problems, but, and this may come off as arrogant, I find that it is generally people that have never had to deal with a problem domain with such irreducible complexities who think that we can solve all of our problems by breaking up work into smaller chunks. Sometimes you also have to deal with business requirements that effectively turn accidental complexity into irreducible complexity. Like, yes, technically things like regulatory compliance are accidental complexity but we also can't just simplify them away without facing serious repercussions. It's also much much easier to maintain context and state in problem domains you have worked in extensively for years, and you tend to be able to write more concise yet still complete descriptions of things within that problem domain. I suspect that has something to do with why the author only adopted this working approach later in life, in addition to the health problems he mentions. For instance, I find that I can pick up physics and math problems with minimal friction because I spent the better part of a decade studying those subjects intensely, but ask me to debug a SQL script (an area where I have minimal domain knowledge) and I will need probably 30 minutes before I can even think a useful thought about it. Most devs do not have the luxury of only working on problems they are domain experts on. Business requirements and capacity are fluid things.
Yes. I currently keep a text document, "NOTES.md", open for whatever project I'm working on. This isn't a bug list; it's just things that I'll need to come back to and deal with. If there's something that has to be dealt with, and it's not in comments in the code, it goes here. This is in the code directory and is checked in with Git, but it's just for my own use.
Some excerpts for a large C++ program: