You mean when you sit down at your keyboard 45 minutes after you popped those Adderall?
What it feels like to be in the zone as a programmer
101–110 of 116 posts
Re: What it feels like to be in the zone as a programmer
#102I don't think I've ever experienced anything like this. As I practice TDD, my usual workflow is think -> test -> code, code usually being the easiest part. Things like "problems break down instantly", "everything becomes effortless" sound strange and exciting. I wonder how that relates to the concepts of maintainability, cowboy programming and 10x engineer. I've met a few programmers in my career who were able to wri…
> I've met a few programmers in my career who were able to write a huge amount of code doing wonderful things without testing at all. One guy I think of would spend days coding without even trying to compile his code and apparently, except for minor typos he could quickly fix, his code was working when he decided to compile and test it.
A variation of this can be interesting to do as an exercise (in my case, a single-program exercise in school). Keep your problem simple, maybe data parsing or the like. Being in a really bad mood when you start can help.
Cowboy code. Compile. Test. At any failure, delete everything and start fresh.
By the time you code a first-time-working copy you'll probably have dropped a huge amount of unnecessary junk from your code, possibly changed approaches multiple times, and maybe found some patterns in your coding that you'd like to do away with. Nuking those code files can be surprisingly cathartic as well.
Not sure how this would really go in a modern IDE or code editor though....
Re: What it feels like to be in the zone as a programmer
#103When I was single, for most of my big projects I used to get 70-80% of the work done in 4-5 days of being in the zone. And then spend months on changing the bells and whistles. Now I have to be home at a reasonable hour and hopefully in a good mood. So I have become hesitant to even get into the zone, because getting out of this state of high efficiency would make me extremely irritable. How do married people or thos…
I usually don't start work on side projects until the kid(s) are asleep. Only works while they are young I guess. My wife has always been understanding of my personal projects, provided I don't let them dominate every waking hour. When they are older I plan to teach them useful complimentary skills. Graphics design. Testing. Copywriting. Marketing. Sales. :-)
> When they are older I plan to teach them useful complimentary skills. Graphics design. Testing. Copywriting. Marketing. Sales. :-)
That's not what most people mean when they say "growing a company."
Re: What it feels like to be in the zone as a programmer
#104[deleted]
Re: What it feels like to be in the zone as a programmer
#105I don't think I've ever experienced anything like this. As I practice TDD, my usual workflow is think -> test -> code, code usually being the easiest part. Things like "problems break down instantly", "everything becomes effortless" sound strange and exciting. I wonder how that relates to the concepts of maintainability, cowboy programming and 10x engineer. I've met a few programmers in my career who were able to wri…
I do that thing, where I just start coding from scratch.
Example: When programming in haskell, I just write the types (not always) and undefined most things and only then I start implementing. Whenever I make a new function, it gets composed by a bunch of other functions that are not yet implemented (undefined's) and eventually this converges.
Refactoring is then based on equality principles in my head. Yeah, it fails sometimes, but that's why pure functions and type safety feels so important sometimes.
Re: What it feels like to be in the zone as a programmer
#106Earlier quoted context omitted.
>No amount of control of my environment will put me in the zone when I'm working on boring code. adderall
As an ADD person who has to take it regularly, I can say that it can just easily focus you on replying to anything of interest on Hacker News... so no, doesn't work this way.
Yeah I've lived it. You have to get to work right away so when it kicks in otherwise you'll generally keep doing whatever you were doing when it did. It can turn you into a god of productivity if you use it right or a degenerate jacking off for 12 hours straight.
Re: What it feels like to be in the zone as a programmer
#107I don't think I've ever experienced anything like this. As I practice TDD, my usual workflow is think -> test -> code, code usually being the easiest part. Things like "problems break down instantly", "everything becomes effortless" sound strange and exciting. I wonder how that relates to the concepts of maintainability, cowboy programming and 10x engineer. I've met a few programmers in my career who were able to wri…
For Powershell, I made a few functions to automate the process. I have:
* New-ModuleFile to create a new module file.
* Insert-TextIntoFile gives a way to specify New-Function, New-Parameter, and any other Powershell function or Cmdlet parenthetically, so adding a function to a module file is a one-liner. I use the alias "instxt".
* New-Function provides the function punctuation and my closing flags.
* New-FunctionStatement (alias NFS) helps lay out any conditional function, including placing punctuation (brackets) and closing flags.
- Instead of typing all the brackets and parenthesis and variable names, I can type "nfs if text -scriptblock '$text' -else '"No Text"'"
* New-Parameter helps you specify Parameters and their numerous variables, such as Type, Mandatory, Position in the arguments list, Validate-Set List, and From Pipeline.
- Pipeline is a Powershell way of chaining Foreach in an ad-hoc fashion.
* Get-History returns previous commands as objects; these go nicely into "instxt".
- A common workflow is to create the function in the "instxt" statement, and have New-Parameter and Get-History as arguments.
- This way, a previously-tested function can be dropped straight into a module as a new function, with parameters already set up. From there, the module can be simply reloaded, and that function used as any loaded function.
The agility this gives is almost indescribable, and I wish I had a better way to demonstrate. Suggestions?
Re: What it feels like to be in the zone as a programmer
#108I find that doing TDD makes it much easier to get in the zone; more importantly, it helps to get back into the zone if I get off track. I typically stub out a bunch of tests (just empty methods named based on what I plan to test), then go one by one and fill in the tests and write the implementations. In the codebase I work in, we use a lot of mocks / fakes, so I typically write my tests "in reverse" - first the veri…
The style of work you described sounds like torture to me.
I don't know why the idea of TDD sounds so terrible to me but it does.
Re: What it feels like to be in the zone as a programmer
#109Earlier quoted context omitted.
As another anecdata, the only way I've landed there more intentionally is with the two beer buzz. Working late on a project that is behind and you grab two slices and a six pack. Two beers in (and one every hour) and all of a sudden you just start tearing through code. I've had this happen to me countless times. I think it is because a lot of engineers have a brain that is spinning 1000% all the time and a couple of…
Sounds like the Ballmer Peak: https://xkcd.com/323/
Beat me to it. ^^
Re: What it feels like to be in the zone as a programmer
#110I find that doing TDD makes it much easier to get in the zone; more importantly, it helps to get back into the zone if I get off track. I typically stub out a bunch of tests (just empty methods named based on what I plan to test), then go one by one and fill in the tests and write the implementations. In the codebase I work in, we use a lot of mocks / fakes, so I typically write my tests "in reverse" - first the veri…
The style of work you described sounds like torture to me. I don't know why the idea of TDD sounds so terrible to me but it does.
Because it sounds like "start with tests, design and plan never". Too often
tests-first is a substitute for a thought-out architecture and data flow.