<i>"Maintain context outside of your head at all times"</i><p>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.<p>Some excerpts for a large C++ program:<p><pre><code> 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.</code></pre>
>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.<p>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.
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.<p>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.<p>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.<p>I find that I have to make a practice of ignoring my refactor instincts, because there usually just isn’t anything I can do.<p>Externalized context definitely helps, but 1 year in, I’m finding my brain has not adapted to this reality.<p>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.<p>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 <i>in the code</i>. 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".
With "Stop trying to make hard work easy" [1] on the HN front page, it reminded me of this that I refer people back to regularly.<p>[1] <a href="https://news.ycombinator.com/item?id=23154519" rel="nofollow">https://news.ycombinator.com/item?id=23154519</a>
Maybe we could just not interrupt programmers.<p>The current demise of offices has done wonders for engineer productivity.<p>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.<p>It takes a surprising amount of willpower to stick to the exercise schedule. Call of the zone is alluring.<p>In case anyone here is in a similar situation and has any tips, please share ...
Unfortunately the real way to be an "interruptible programmer" is<p>a) be self-employed, i.e. be your own boss
b) have the kind of good work hygiene<p>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.<p>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 have been trying <a href="http://roamresearch.com/" rel="nofollow">http://roamresearch.com/</a> (or Dynalist) to keep a daily log of my findings, projects and (some) tasks.. - its going quite well.
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.<p>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.<p>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.