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 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.
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.
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.
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 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.
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.
I've found the same for designing circuit boards. When you are done, save it and look at it tomorrow, errors will be obvious.
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.
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 :)
Easier if it's a conference call, of course.
Reading that website these days feels like going back in time before 'agile' became a buzzword only, and dominated by enterprise scum masters.
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.
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.I’m arguing this is not such a great thing because I’ve noticed a few things that have occurred due to me being like this:
The gf will complain, a lot, that you don’t spend enough time with her.
You disregard eating sometimes (and I try to stay as fit as possible, sometimes I will just forgo gym because work > everything)
I have almost 0 balance for personal life, most of time from waking up is straight to
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 ...
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.
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:
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!
https://www.wired.com/2014/01/a-vibrating-watch-that-messes-...
Discussed here:
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.
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.
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.
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 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.
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.