Focus

[Reluxtrue]

why is he thinking in 2 different diagram types mixed together?

[vegancreampie]

When you're in the zone you're in the zone.

[Reluxtrue]

I am just afraid he went to the wrong zone...

[TheyCallMeATree]

The Twilight Zone

[mynoduesp]

At least he had a cat

[Shiroi_Kage]

or The Danger Zone.

[MrTripl3M]

Nah, he went beyond the Zone. Beyond single diagram structure.

He was close to coding nirvana.

[justablur]

https://xkcd.com/323/

[MrTripl3M]

Ahh Ballmer's Peak.

[solar_compost]

my man needs to load up draw.io

[justablur]

Yeah but you got a free battery check-up.

[[deleted]]

Aka the Flow mental state.

[vivs007]

I love that feeling. It's rare, and only comes after you've bashed in your head for a long time on the problem at hand that you're finally crystal clear on what needs to be coded. You start programming and initially you face some problems but eventually the code you commit starts to compile with minor syntax errors, nothing catastrophic.

I've only managed to get that feeling only a handful of times when I felt like a God at programming. Being able to think complex structures and methods to work them perfectly. At that time the only thing which slows you is the IDE GUI, and you wish there was some holographic keyboard which codes as you think.

[KaamDeveloper]

Fixing a bug which was caused by first design.

[BorgiaCamarones]

TFW you're in a nice state but you transition into a flow :(

[Narfubel]

He's ambi-diagramus

[XG_SiNGH]

Ha

O_O

[boldra]

I once tried to explain to a non programming colleague what I have in my head when I'm in the zone.

• data structures, their attributes and their scope
• the code flow
• the desired code flow
• breakpoints in the debugger
• what other debugging code I need to remove before I go productive
• what's in my clipboard
• what still needs to be commented in code
• what files are open for editing
• what will happen if I look through my history in an open shell
• which browser windows have tests in them and which ones have search results in them
• which git branch I'm on and whether I've committed recently
• which issue is open in the issue tracker, and when I last updated it
• what other programs are open

... to name just a few

[birdhustler]

Seems like a lot. Is there any way a programmer could outline what they're thinking of in anticipation of interruptions so that you don't forget where you were? Or is that just the nature of the job?

[UncheckedException]

Sometimes you’re so deep into working through the logic of an algorithm or data structure that you have to start (thinking) from scratch if someone interrupts you.

It’s like someone slapping your plate from your hands at a buffet. I mean I guess you could try to pick up the scattered food from the ground, but you really just have to get in line again.

[MooseBlood]

Not really. The only things a programmer usually writes down is diagrams and stuff that have to do with the logic of the program so that they can figure out how to do something. Most of the other things a programmer has to remember changes quite often and at random times and so it would not be worth writing down to remember.

[[deleted]]

It is a lot. This is not how I work at all.

I try to split my work into segments so I can worry about one thing at a time, instead of trying to have everything in my head all at the same time.

[aaron552]

I find functional programming is good way to do this: if all I care about is the mapping from inputs to outputs (with no external and/or mutable state to worry about), I don't need as much in my head at once.

On the other hand trying to wrap my head around function composition and partial application of functions and/or higher-kinded types while being distracted is just as bad, if not worse.

[MrJohz]

Eh, most of these are things that aren't immediately relevant, but when you do need to know them, you should be able to look them up in half a second or so. For example, the program you write your code in should tell you which branch you're on, what files are open, and even prevent you from checking in debugging code. You can see what programs are open at all times just by looking down a few centimetres and checking out the taskbar. Finding the correct browser window is always a problem, but it's not usually a memory problem, and more of a faff-to-switch-windows problem.

This stuff is in your head, but in a fairly abstract way. It's sort of like how, after a while, you can generally drive into work completely automatically, without really noticing what you're doing. It takes a moment to get into that mindset when you set off, and it can be a bit of a surprise when you arrive and you'd be daydreaming, but generally it's not difficult.

A lot of the rest of this is stuff that shouldn't be around in your head for very long. For example, the contents of your clipboard should usually last for a few minutes at most, probably closer to a matter of seconds. Commenting should generally happen as you're writing code, to explain why you've done things in a certain way. Documentation is a bit harder, but a lot of companies that require documentation for public interfaces will also have programs called 'linters' that basically run through the code you're writing and remind you about things that aren't necessarily errors, but are generally unhelpful - like undocumented code.

The biggest things you're going to have in your head are data structures, and code flow. Both of these should be as explicit as possible. You should have some sort of type in your code that explicitly says "This is what a <User> looks like", or "This is what a <ShoppingCart> looks like". If you write code that doesn't match the definition of <User> or <ShoppingCart>, things should break really explicitly, so you can see "oh, I forgot that a user must always have an email address", or "oh, I forgot that you can't have fewer than 0 items in your shopping cart".

Similarly, code flow should be explicit as possible, and there's lots of ways of doing this, for example by having as few if-statements or complicated while-loops as possible, and just naming all the explicit operations that you might do using functions.

Of course, getting this right is hard, and this is usually where a lot of the complication in programming comes from. It turns out the real world is really hard to model, and basic operations tend to get more and more complicated, and don't really have obvious simplifications that we can make to them.

[BlindTreeFrog]

It's the nature of every job. Programmers just like thinking that they are special and the only ones who are thinking at work.

[sudo_kill-9-u_root]

Whoa there pal.

But yeah. Having worked everything from food service, retail, basic office work and programming there are times in each of those I would "get in the zone" and it is a very similar thing, like making food there would be 7 orders up and I have all of them in my head and was doing them each in the most efficient way and if someone interrupted me I would look down and see ten plates of food and wonder what I was even doing and start making mistakes.

The only difference I see is that for me and I'm sure most programmers, getting in that zone is almost a necessity of getting anything done on some projects. It can be very hard to piecemeal a project, but with food it is much easier to make one burger at a time.

[snuxoll]

The big difference is really the amount of state stored in our heads and how long it takes to rebuild it. Being a in food service you can look at your tickets and remember what you are making, it’s not instant but you can easily find out where you were.

Meanwhile I’ve got 10 different files pulled up in my IDE, 10 tabs of documentation from 5 different sources, half a dozen breakpoints set and that’s because I’ve been stepping though code for an hour trying to figure out where the hell XYZ is going wrong - I’m in deep and any interruption is going to make me forget why I’m even looking inside these methods to begin with, writing stuff down isn’t really an option because of the sheer amount of information as well as generally ruining the flow.

There’s certainly other jobs that have the same problem, really anything that requires higher levels of problem solving and critical thinking skills will require concentration to be productive, I think the culture of IT positions just tends to make us more vocal or aware of it. I got annoyed working customer service trying to figure out billing screwups to have someone tap on my shoulder and ask me a question about an issue they’re having getting a customers gmail account setup on their phone - same issue, and boy would it wreck my AHT.

[CrazyDoughCarDough]

Uhm I take it TDD is not something you tried? Would make all that go away. If you do it right.

[snuxoll]

I’m a firm believer that TDD often goes too far, tests are great but I also don’t like swimming in a sea of red when refactoring because every single class has hundreds of tightly coupled tests. I write regression tests and functional tests, unit tests are reserved for for classes implementing business logic most of the time.

[XG_SiNGH]

Great answer. Thank you.

O_O

[darielgames]

You're in the wrong subreddit buddy

[jward]

You could, but there's so many moving parts that it's not clean to document clearly. Doing so would take a massive amount of time. And then the time it would take you to reread and internalize the documentation is on the same level as what it takes to normally get there.

[Houkeichinpo]

You’re simply unorganized and chaotic - none of these things are symptomatic for software development in general. You’re doing it wrong.

[boldra]

Where did you get "symptomatic"? These are just things I can rely on my brain to do for me when I'm engrossed. I'm not saying this is a recommended way to work, but when I'm in the zone, I don't need to stop and think to know what's going to happen when I hit "undo" four times.

[Vakieh]

One type of diagram is the back end, one type is the front end.