OJFord 23 days ago [-]
> in my team culture it’s not frowned upon to “snoop behind” people writing code. Whenever I sensed something interesting going on, I’d roll around and watch what was happening.

Agh, I'd hate that. In fact if anything interesting had been going on on my screen it would immediately stop, no way I could work with someone watching.

I struggle enough at desks with my back to a door or where people walk by, just can't stop myself from being distracted and looking.

(It's not that I'm not working, or otherwise doing anything I shouldn't be, it's just.. distracting is the best word I have. It's not where I'd sit in a restaurant, and I've despised not having a choice but to sit at such a desk at work.)

neilv 23 days ago [-]
My 'favorite' (it seems funnier, with some distance) was when I arrived at a new job as a Research Scientist in a university lab, to execute on a project of a couple PIs... I immediately find out I'm being jammed into this packed, messy, mouse-infested, nest-like office with ~5 grad students (working on other things, not collaborating). With a sense of dread, I sit down at my assigned kidney bean-shaped desk in the middle, someone sits down at their desk that's pushed up against mine... and he's looking at a diagonal of the side/front of my face, from just a few feet away, and seems fine with that.

He's a nice person, and I understand not all people are wired to realize this is a problem for some others, but this is reallocating too many IQ points, away from designing and coding and writing, to social interaction/awareness modes. Plus the other distractions. There was no way I could immerse enough in some of the work, and stay immersed.

(I'm happy to do group brainstorming and problem-solving around a whiteboard, etc., as well as to mentor. But most of my time is spent programming, designing, and writing, which I usually do best solo and focused. Nor do I want to be working all day, every day, almost breathing down each others' necks. For many introverts, and people who like to focus fully on a problem, being packed up against other people is taxing, not energizing.)

In the end, I brought in a laptop from home, and worked every day, cafe-style from the lunch tables in the elevator lobby area of our building floor. Which was suboptimal, but something I could make work. People would come over when necessary, but we weren't sitting on each other's laps. I also got good at quickly cleaning lunch tables without interrupting my thoughts. When my PI renewed my appointment another year, I declined, mainly for a different reason, but the physical work environment made the decision easier.

harrisonjackson 23 days ago [-]
For me, it depends on who is creeping. A junior engineer, I'd probably pull them up and start explaining what is going on. A fellow senior engineer I'd probably take a welcome break and ask them to grab a coffee - the only reason they'd be lurking lol. If it is a PM or someone else it might put me on edge - likely because they wouldn't have the context to understand what I was working on and if they didn't say anything I'd just be wondering what they wanted...
Scarblac 23 days ago [-]
So in all three cases, your focus is gone and what you were doing has stopped.
SamuelAdams 23 days ago [-]
Eh, not really. Not all engineers work in high-pressure environments where focus is essential. Some senior engineers really enjoy teaching others. Some of the best mentors I've learned from were the ones who were happy to spend an entire Friday afternoon showing me how they would solve an interesting problem.
aspaceman 23 days ago [-]
Helping a junior and maintaining relationships with your fellow seniors is a part of the job too.
monsieurbanana 23 days ago [-]
But surely there's ways of doing that without making people lose their focus.
nickpsecurity 23 days ago [-]
Such as assigning times for focused vs collaborative work.
bochoh 23 days ago [-]
Yes, a vibrant meme room in a "management expects you to respond to business issues in this room" channel on <slack|teams|etc>
SolaceQuantum 23 days ago [-]
Actually, is there?
OJFord 23 days ago [-]
Yes, you pick the moment (much) better than wandering over to peek over their shoulder when 'something interesting is going on'. IMO that's exactly when you don't, ask them about it later.

To borrow from that cringeworthy scene in The Social Network: He's wired in!

chasd00 23 days ago [-]
also, imo explaining something complex to someone junior often leads to answers to other questions. For some reason, talking through code out loud helps the problem solving process.
harrisonjackson 22 days ago [-]
Which is _okay_ as long as it doesn't happen too often. I work remotely now, but most offices have conference rooms or quiet spaces or respected headphones on policies for when you need headsdown time. If there's no way to signal that you are busy, then that's probably a separate issue than the 3 cases here.
inflatableDodo 23 days ago [-]
The first one, less so. Explaining what you are doing to someone (as long as they get the basics) can be a great way to cement your understanding of what you are currently doing.
rakamotog 23 days ago [-]
The only time I (a PM) would do this is when you are working on validation messages / error messages / user facing text.
afarrell 23 days ago [-]
Error message phrasing is really very important, but it’s probably better to have that refined in code review or to have some explicit step for it.
dotancohen 23 days ago [-]
Error message phrasing should not be in code. It should be in localization files, even for the default language, and not require a developer to modify.
SamuelAdams 23 days ago [-]
Depends on the requirements. I've had many internal-only applications only require one language: English. At that point you can hard code many things, which skips the loading other files, checking different languages, etc.
OJFord 23 days ago [-]
I'd still rather the exact wording isn't in code, personally:


    'I\'m sorry, we\'ve been unable to add the address %s at this time,' \
    ' please try again later.'
(... but that's an ideal I have without ever having worked with it, so what do I know, and ymmv, etc.)
rakamotog 22 days ago [-]
And what is this localization file called? We do not have a system where non dev can commit any change in our product.

We do have a constants file which has all the messages but a PM does not access to code/commit and has to go via a Dev.

rmetzler 23 days ago [-]
It really depends on who‘s the target group. I hate localization in Developer Tools etc, because googling it is harder and a lot of times English is just easier to understand. It’s different for a shopping site.
high_derivative 23 days ago [-]
How would you know this without entering their personal space?
ken 23 days ago [-]
I've read that in feng shui what you describe is called the "command position".

I'm not able to work with my back to a crowd. That's a recipe for anxiety. I quit a company when they moved my desk so my back was to a hallway, and refused to compromise on this issue in any way.

greyhair 23 days ago [-]
This is why, when people complain about cubicles, I tell them how much better a cubicle is than open floor plan.

I have had private offices, two person offices, cubicles, and once in a bull pen with a glass wall. (we called it 'the fish bowl').

Private office comes in first! Cubicle (as long as the walls are at least five feet) comes in a close second.

Open floor plan (or a bull pen) comes in far far far last.

cr0sh 23 days ago [-]
The best time I ever had was in a "bull pen" situation (our team at the time called it alternatively the "oven" or the "barn"). It was at a new job, doing something new to me (server automation), and our team consisted of one of their senior devs, myself, and two really "green" new guys who were also hired along with me. One was new in the sense that they had a fresh comp-sci degree but had never worked in the field before, and the other had worked in the field, but never at an employer (only as a remote contractor).

The place had no open desks for us, so they decided to turn the small conference room (we had interviewed in) into our shared "office". Trouble was, it had no A/C vent in it. Hence, with four people and four computers and four monitors - it became "the oven" (there were other reasons we named it what we did, but they aren't relevant here).

But the camaraderie we built in a short amount of time as a team was beyond anything I had experienced before. We'd keep the lights off, a fan running, and a spotify playlist cranking out weird music (our lead controlled it, he was younger than me by many years - as an older person just turning 40 - his choice of music was both odd, and interesting - I'm glad for this, as I discovered new music genres I never knew existed - like Pirate Metal - yes, Alestorm was one such band).

Eventually we got a portable A/C unit, which made things more tolerable.

Ultimately, though, that room helped to form a team that cranked out some interesting code in a very short period, which I think helped to lead the company to be sold to a larger competitor about a year or so later. I ended up leaving the company (the new owners did a "rehiring" process in which they offered me my position at a 25% pay cut - yeah, sure, let me get right on that).

weaksauce 23 days ago [-]
Cubes are almost always back to the people coming so it’s anxiety inducing to me. An office with you facing the door is the only way for peace in my mind.
mikekchar 23 days ago [-]
If it happens again, I've been told that having a mirror on your desk so that you can see what's going on behind you can help a lot.
inimino 23 days ago [-]
Or if putting a mirror on your desk is the best resolution your employer can offer, run away screaming...
JohnBooty 23 days ago [-]
I tried this and it absolutely did not help.

In a "normal" situation where your desk faces the rest of the room, you would become aware (in an "ambient" way) of people wandering into your field of view.

But with your back to the room/hallway/whatever, you need to explicitly scan the mirror (sort of like polling, in computer terms) with frequency to know if somebody is approaching.

It's like trying to work while also focused on a video playing in a desktop window or something.

Of course, as with anything, some people are not bothered by this. (And, of course, some of those people are fooling themselves into thinking there's zero impact on their focus/productivity)

IloveHN84 23 days ago [-]
After we moved to another floor/office, I forced my team lead to move to the desk with back facing the door while I conquered the desk with a wall behind me, after spending 4+ years with the back facing the open office we had previously.

I improved exponentially my concentration and quality of work while he showed up that previously he was spending large amount of time watching YouTube/news websites/shows instead of doing work and he is frustrated that he has to do real work now.

saagarjha 23 days ago [-]
Or if your monitor is one of those glossy ones, just glance into a darker part.
dillonmckay 23 days ago [-]
I had a coworker try this, and it made her more jumpy, as she would catch somebody in her rear vision across the room.

She would audibly be surprised and distract others.

dotancohen 23 days ago [-]
You likely already have one.

The upper bezel of your monitor is likely shiny black. It makes a great mirror to know when someone behind you is taking interest in you. It is also completely inconspicuous and you do not need to move your head from your monitor to use it.

Sharlin 23 days ago [-]
I’d say that it’s only likely conditional on having a Mac.
cortesoft 23 days ago [-]
Wouldn't that cause even more distraction as you see all the people walking behind you?
mikekchar 23 days ago [-]
Apparently (it's not something I suffer from), people who prefer to be facing the aisle tend to glance out at people from time to time, which makes them feel at ease. Having the people at their back makes them uncomfortable because they can't keep tabs on it. For some people, this is apparently so bad that even if they are in an individual office they need to have a window, or keep the door open.
OJFord 23 days ago [-]
> I've read that in feng shui what you describe is called the "command position".

Thanks - now you say it, I think I've heard that before. (Perhaps from my father, who I know 'suffers' from the same.)

And in fact, when working from home (nobody around so it's not about being in 'command' of others at all, as a quick search tells me it isn't in feng shui either) I often prefer to sit at a table where I can see down the corridor to the front door.

Or when it's hot, on the balcony (as I am now) sitting back from the table such that my back's to the corner and my peripheral vision covers both out over the balcony to outside, and through the windows into my flat.

...interesting. It's totally sub-conscious - I always know where I want to sit in a room, or at a table in a restaurant, etc. it doesn't require thought but it certainly isn't random. I don't think about it while sitting down, but I'm sure if you asked me afterwards why I was sitting there I could tell you.

philwelch 23 days ago [-]
I startle very easily, especially if I'm snuck up on from behind, so if anyone comes up behind me, I unintentionally scream loudly as soon as I notice them. I have found that this tends to discourage that sort of behavior.
bronxbomber92 23 days ago [-]
We have a similar culture on my team. When I was a junior engineer, being able to poke my head into any open office that sounded like it had an interesting conversation going on was really an invaluable way of learning.
losteric 23 days ago [-]
Listening to or participating in technical conversations is just regular business, but the proposal of looking over someone's shoulder sounds very distracting and unnecessary...
rbavocadotree 23 days ago [-]
It's also strange in that I don't think I'd get very much out of simply watching anyone work, unless they were also giving live commentary or something.
nitrogen 23 days ago [-]
There was an article posted on HN a while back that claimed that the best way for beginners to learn a new skill is to watch an expert just work, without any commentary or explanation. I tried finding a link, but couldn't come up with working search terms on DDG, Goog, or HN.
dillonmckay 23 days ago [-]
This was an interesting article about the trend towards robotic surgery and the new methods to gain experience in such an environment.


Bekwnn 21 days ago [-]
Casey Muratori's and Jonathan Blow's streams are pretty great in this regard. Both do low-level gamedev.
tc7 23 days ago [-]
Really seems like I should be better at golf, then. :tear
arkh 23 days ago [-]
That's where pair programming can shine: when I see a junior who need help, I'll ask if they don't mind me coming around and helping. Just asking the right questions and guiding them to find a solution to their problem usually do the trick. And it helps me see the pain points of our code, documentation and specs.
kemiller2002 23 days ago [-]
I completely agree. Most of the time when I code I am working through problems. It's unrefined and messy until I'm done. You want me to show you what I did and explain how I got there when I'm done? Great! I'd love to but not when I'm in the middle of it. I rarely get things correct the first time, and I would like to not have to be self conscience about people judging how I think.
pkrotich 23 days ago [-]
So how do you handle pair programming? It’s almost the same thing to me.
denton-scratch 23 days ago [-]
I think pair programming requires some 'investment' at the team level. For example, the work environment (think desk arrangements) need to be set up to make pairing natural.

It's helpful if pair programming is the default mode (i.e. a dev will only go solo when there's a consensus that pairing would be counter-productive).

If you pair-off at the morning standup, so that ongoing tasks retain one dev from yesterday and gain one fresh dev, then after a couple of weeks everyone on the team can cover for anyone else, and everyone has a birds-eye view of the whole system. This was a revelation to me; prior to my encounters with pairing, I'd never worked on a team where anyone had a good overview of the whole system, including the leader. Morning standups help, but pairing-with-rotation does a much better job of knowledge-distribution.

Re. Sociability: I've paired with some very nerdy, shy people. It generally worked out well; most nerds are just fine when they are explaining what they are currently nerding about.

I've paired with people who were much brighter and more knowledgeable than me, and the other way round. Either way, it worked out fine (as long as you don't develop a Master-Apprentice syndrome).

Pairing involves quite a lot more mental effort than solo coding. I was always dog-tired after a day of pairing. Keeping track of what your pair is up to (or making sure your pair is keeping up) requires attention. And IME breaks are generally shorter.

I only had a problem when I had to pair with someone quite far along the aspie continuum; he was bright, but he was completely unable to explain what he was doing, and his code was far from self-explanatory. If you see coding as a way of communicating with programmers, rather than with machines, strongly aspie types become a workplace hazard.

OJFord 23 days ago [-]
I've never worked at an org or on a team with an explicit 'we do pair programming', but in general if someone wants to explicitly start watching while ai walk through something, or have me watch whilethey show me something and we figure something out together, that's fine.

I will fumble the keys and be much slower if I'm the one being watched, but I'm fine with that because I know they're there and they asked.

I'd still be bothered by others walking past behind us while the person who came over to 'pair program' (if I can call what we're doing that) watches and doesn't bother me.

marcosdumay 23 days ago [-]
I don't. I could never really pair programming, even in school.

Interestingly, I can share my screen with people that have different tasks than mine. I just can't make it work when both people have the same state of mind.

bryanrasmussen 23 days ago [-]
pair programming is really a forced socializing in a field where a lot of people have trouble socializing, never really understood how it got as far as it did.
TeMPOraL 23 days ago [-]
Pair programming is an anti-procrastination trick that works by setting two people in a situation where both are afraid to lose face by trying to goof off. This works, but builds up anxiety.
neilv 23 days ago [-]
Pair programming seems to be social in some ways, but I could imagine two programmers with very little social awareness or self-consciousness being able to find a cadence for pair-programming.
filoleg 22 days ago [-]
Depends on the definition of pair programming imo.

Bad definition (the one I encountered in school): two people of about the same skill level sitting at one computer and programming together. I hated it, akin to my hate of backseat drivers.

Good definition (the one I encountered at my workplace): as a junior engineer, I was tasked with implementing this tricky caching thing in one of our systems that I had zero previous experience with. One of our senior engineers was tasked with helping me with that. I would implement as much as I could myself, and when I get stuck, the senior would either give me hints on how to get unstuck or program some parts himself while explaining to me how and why he did things a certain way. This helped me out tremendously in my skill development and got me running confidently in our codebase really quickly.

larzang 23 days ago [-]
Interaction between devs is unavoidable, at the code review stage if not sooner. Pair programming provides tighter feedback loops and helps get things done quicker than playing CR tennis after a lot of hours have been sunk into something.
sharadov 23 days ago [-]
Sometimes it's just working collaboratively, creating an atmosphere where you encourage the "junior folks" to ask questions without judgment. Also whenever you stumble on something interesting you share. I miss this aspect of my current job, am 100% remote and miss those discussions.
OJFord 23 days ago [-]
I am a 'junior folk'; I don't have a problem collaborating, the people walking behind me didn't care what was on my screen and many of them wouldn't have understood if they'd looked (different roles) - it's just the fact that I can feel people there that distracts me and compels me to look, even though I 'know' they're not watching, couldn't care less, and will be gone in a second.
scarejunba 23 days ago [-]
How interesting! I thoroughly enjoy it. Oddly though, I always hated performing an instrument in front of someone else. I can only play for myself :D
teddyh 23 days ago [-]
> Naming your clusters? Naming them after the service that runs on them is great, till the point you start running something else on them too. We ended up naming them with our team name.

This is covered by RFC 1178¹, Choosing a Name for Your Computer (from 1990):

Don't choose a name after a project unique to that machine.

A manufacturing project had named a machine "shop" since it was going to be used to control a number of machines on a shop floor. A while later, a new machine was acquired to help with some of the processing. Needless to say, it couldn't be called "shop" as well. Indeed, both machines ended up performing more specific tasks, allowing more precision in naming. A year later, five new machines were installed and the original one was moved to an unrelated project. It is simply impossible to choose generic names that remain appropriate for very long.

Of course, they could have called the second one "shop2" and so on. But then one is really only distinguishing machines by their number. You might as well just call them "1", "2", and "3". The only time this kind of naming scheme is appropriate is when you have a lot of machines and there are no reasons for any human to distinguish between them. For example, a master computer might be controlling an array of one hundred computers. In this case, it makes sense to refer to them with the array indices.

While computers aren't quite analogous to people, their names are. Nobody expects to learn much about a person by their name. Just because a person is named "Don" doesn't mean he is the ruler of the world (despite what the "Choosing a Name for your Baby" books say). In reality, names are just arbitrary tags. You cannot tell what a person does for a living, what their hobbies are, and so on.

1. https://tools.ietf.org/html/rfc1178#page-2

Spooky23 23 days ago [-]
Naming standards are the ultimate bikeshedding event. Everyone has an opinion and camps develop for various schemes.

The last time this happened, I happened to be in a position of influence for the final decision for naming standards. We took an approach designed to piss off everyone... license plates. We used sequential numbers prepended by a pronounceable string, and random words, selected by a system, for internal services.

Overall, everyone is pretty happy with it. YMMV.

phnofive 23 days ago [-]
I have been on both the receiving and producing end of a similar decision making process whereby all stakeholders are consulted, and then a solution is provided which has as its only real design consideration - beyond being effective - that no-one gets exactly what they requested.

Is there a name for this kind of anti-consensus decision making?

landhar 23 days ago [-]
Not sure if there’s a name for this, but my favourite example is settling on UTC as the acronym for Coordinated Universal Time:


yen223 23 days ago [-]
ISO stands for the International Organization for Standardization, for largely the same reasons.
Rediscover 23 days ago [-]
Maybe I got the wrong person (on the phone), but it was explained to me the name "ISO" was the Greek word for "sameness" and that Français and English just happened to form /meaningful/ representations for an acronym.
kbutler 22 days ago [-]
"IT'S ALL IN THE NAME Because 'International Organization for Standardization' would have different acronyms in different languages (IOS in English, OIN in French for Organisation internationale de normalisation), our founders decided to give it the short form ISO. ISO is derived from the Greek isos, meaning equal. Whatever the country, whatever the language, we are always ISO." https://www.iso.org/about-us.html

But I'd tend to call BS - if it wasn't ever an acronym, why capitalize all three letters?

The google ngrams are also suggestive:


dotancohen 23 days ago [-]
The Greek ισο "iso" does mean "equal". I do not know if that influenced the naming of the organization, though.

You see this word in many English roots, such as isotropic, isometric, isomer, etc.

mindcrime 23 days ago [-]
In a similar vein, the acronym for Web Ontology Language is OWL[1].

[1]: https://www.w3.org/OWL/

Spooky23 23 days ago [-]
Great question! I wish I knew!

It’s a weird scenario as people are very emotional about their chosen position during the discussion, but literally nobody gives a hoot once a decision was made.

In our case, multiple organizations were merged, so the perception one camp “winning” was important to avoid.

HiFaraz 23 days ago [-]
I'd call that a compromise.
mixmastamyk 23 days ago [-]
I like the sound of "anti-compromise."
dillonmckay 23 days ago [-]
TeMPOraL 23 days ago [-]
No; the point here is to pick the worst possible compromise out of compromises that solve the problem effectively.

It's like you're dividing an 8-piece pizza between 3 people. Everyone's minimum desire is 2 pieces, compromise solution would be 2 and 2/3 split, and people keep arguing why they deserve more. However you - the decision maker - decide instead to give everyone 2 pieces and throw the remaining 3 pieces into the bin, because shut up and get back to work.

phnofive 22 days ago [-]
You understand perfectly: everyone got enough food to keep going, and they are equally dissatisfied with the result. I might take a step to the left by ordering known-unpalatable toppings and provide no further allocation instructions, but the effect is the same.
dillonmckay 23 days ago [-]
If there are 3 people, and they each get 2 slices, that is 6 slices.

So, throwing away 2 slices, because there is 8 total, is fine, as you stated that is everybody’s agreed minimum desired amount.

And there is no knife, nor protractor.

What is the difference between the worst and best compromise? If it is a compromise, it is a compromise.

phnofive 22 days ago [-]
Anti-compromise: A solution which pleases the fewest parties possible while still meeting each party’s needs.

Compromise: A solution which pleases the most parties possible while still meeting each party’s needs.

bryanrasmussen 23 days ago [-]
I'm in Denmark, it has been my experience that the most common naming scheme (I would say omnipresent naming scheme almost) is to use the old Norse Pantheon for names.
gilesgate 23 days ago [-]
Similar in Greek academic networks, adapting to local mythology. The amount of routers and mail servers named 'Hermes' was ridiculous.

Different experience in English academia, where I encountered random names (e.g. 'mira' for a shell server and 'laplace' for a Physics Dept server). The acronyms could at times be interesting. Particular favourite was a 'central university network time' server. That was later renamed to ntp.*.ac.uk, after stern recommendations.

rimliu 23 days ago [-]
Around 2000 I was working at the small bank that had servers named by currency. Development server happened to be "dong". Eudora had some spicy language detection and used to show me some red chili peppers every time I'd mention that server in email.
the_jeremy 23 days ago [-]
In Colorado, USA, all 5 companies I've been inside conference rooms of use specific mountains (or ski towns) in the area. I've been in meetings in Longs Peak in 3 different companies.
dagw 23 days ago [-]
Same experience in Norway and Sweden. Followed very closely by sci-fi/fantasy characters or authors.
zymhan 22 days ago [-]
I've noticed the Pritunl VPN suite uses that to name nodes. Two words (adjective + noun) and a number.
kissgyorgy 23 days ago [-]
> Naming standards are the ultimate bikeshedding event.

I hope you never write a single line of code with this mentality...

one-punch 23 days ago [-]
There is a cute name for, er, the two ways of naming systems: pets naming vs cattle naming [1]. I think naming after services is like pet naming, while naming them by numbers is like cattle naming.

Pets Service Model

In the pets service model, each pet server is given a loving names like zeus, ares, hades, poseidon, and athena. They are “unique, lovingly hand-raised, and cared for, and when they get sick, you nurse them back to health”. You scale these up by making them bigger, and when they are unavailable, everyone notices.

Examples of pet servers include mainframes, solitary servers, load balancers and firewalls, database systems, and so on. Cattle Service Model

In the cattle service model, the servers are given identification numbers like web-01, web-02, web-03, web-04, and web-05, much the same way cattle are given numbers tagged to their ear. Each server is “almost identical to each other” and “when one gets sick, you replace it with another one”. You scale these by creating more of them, and when one is unavailable, no one notices.

Examples of cattle servers include web server arrays, no-sql clusters, queuing cluster, search cluster, caching reverse proxy cluster, multi-master datastores like Cassandra, big-data cluster solutions, and so on.

[1] https://medium.com/@Joachim8675309/devops-concepts-pets-vs-c...

shagie 23 days ago [-]
The thing I found when naming things was to have as much information packed in the first syllable in a way that was reinforced by all the remaining syllables (that becomes more important when there are a variety of accents in the workplace).

One set of systems I worked on, a team had names based on islands. Two of the test machines were Trinidad and Tobago. Upon hearing the first syllable, it was clear that these were the test machines. Every additional bit beyond tri or tƏ was distinct and reinforcing that the first bit was heard correctly.

They also had boring names like dc2f1a3r1s4 and foo-test1 (depending on who was interested in the machine).

The problem that I've found with names like asfcap1234 is that one has to listen to every piece of information and remember it to properly identify the machine. With every character being important and distinct, there isn't any reinforcement or mnemonic checksum to make sure you've got it right.

I will note that this is from the era of servers (and even before VMs started being the thing).

It is very true that once humans no longer reference the machines by name, the ability to name them becomes less important.

As a counterpoint to RFC 1178, consider RFC 2100 - The Naming of Hosts https://tools.ietf.org/html/rfc2100

philwelch 23 days ago [-]
If you designate your servers with numbers or meaningless identifiers instead of names, you also won't ever feel guilty about killing and replacing them. I believe this is (somewhat gruesomely) called the "pets vs. livestock" approach.
taneq 23 days ago [-]
If you believe people can't get a little attached to "prodsys3" or whatever, then you underestimate the sentimentality of some of us. ;)

Of course, the other thing you can do is name server roles rather than specific hardware, so all of your servers are immortal, Ship-of-Theseus style.

xmprt 23 days ago [-]
A farmer gets attached to his cattle but when the time comes for one of them to go (either old age, to sell the meat, or there's a newer faster cattle that management has enforced a mandatory deadline of Q3 to migrate to), it's understood that it's time to say goodbye.
D-Coder 22 days ago [-]
At one job, the servers were named after characters on Gilligan's Island.

Problems with Ginger were being discussed at one stand-up, and an engineer who didn't care about that quietly said, "Blah blah blah Ginger, blah blah blah Ginger." I almost fell over laughing.


cortesoft 23 days ago [-]
Yeah, I work for a CDN with tens of thousands of machines, and I still miss wac052.mad when we decommmed that POP 5 years ago.
sergiosgc 23 days ago [-]
prodsys3 pales in comparison to when I had to decommission gandalf and galadriel.

Now when name them by physical position in the rack/bladecenter.

Spoom 23 days ago [-]
At least the memes write themselves.
bitwize 23 days ago [-]
Every time someone trots out that old analogy, I think of my uncle who has a small dairy farm in the U.S. midwest with over 50 head of cattle. He gave each one a name, and when one is sick, he cares for it until it is better if possible.
dotancohen 23 days ago [-]
I know of a man with over 50 children. I'm friendly with his neighbour, who has almost 40. 50 is a number that a human can still care for and love each one individually.

NB: Yes, I know that the Wikipedia list of "people with many children" makes 50 look like a record-breaking number. That list is Western-centric. Though 50 is a huge number of children even by Arab standards, it is not unheard of.

philwelch 23 days ago [-]
If you can have four wives, 50 children is only about 12/13 per wife, and 12/13 kids seems like a high-but-achievable number in our monogamous culture. So I find that very believable.
cortesoft 23 days ago [-]
Right, because 50 is still a small enough number to care about each one. If he had 20,000....
xorcist 23 days ago [-]
It is also misguided. Not only do people get attached just as easily to meaningless identifiers, but when stripped of their mening people are more likely to re-use identifiers, not less.
stefs 23 days ago [-]
in my home network i name my computers after animals, whereby the power/size of the computer roughly resembles the size of the animal.

my beefy desktop may be the whale, the nas is the rhino, the notebooks are roughly dogs, the raspberry pis are small animals like mice, the chromecast is e coli.

plus good: i'm never going to run out of animal names.

sk5t 23 days ago [-]
Nice! Could take a turn for the worse when you need something smaller than E. coli though--you'll be wishing you named the Chromecast "tardigrade" when some lightswitch has to be named "herpes."
yjftsjthsd-h 23 days ago [-]
Rest assured, IoT deserves to be named herpes...
kd5bjo 23 days ago [-]
My parents use the same scheme; they have developed a tradition of buying a corresponding stuffed animal to live next to the computer.
zrail 23 days ago [-]
I use Simpson’s bit characters. Never gonna run out of those.
jquery 23 days ago [-]
I use One Piece characters for the same reason. My most beefy PC is Monkey D. Luffy and so on. Like you, I like the whimsy in using names from a fictional world, and some worlds have more names to choose from than others.
dillonmckay 23 days ago [-]
My first job, I named each web server off of a different Simpson’s character, all attached to a big KVM, so I customized each desktop to the character, so I could easily tell what server I was in.
AstroJetson 23 days ago [-]
Some people thought it was annoying, but the desktop picture had the character in the upper right corner. Away from the Icons, but you could glance ad see who it was and go right to it.

Also have used Simpson's for test data. There is some built in structures that can be used Abe-> Homer == Marge > Bart, Maggie, Lisa. Lots of people mostly remember them.

ljm 23 days ago [-]
I went for traditional Russian names, because I’d also have a healthy amount of diminutives to use if the device behaved well, and could fall back to the full patronymic version if it acted up.

It’s like having a little family.

jolmg 23 days ago [-]
I'm a bit reluctant to be that guy, but... E. coli is not an animal...

There are some really small animals, though:



teddyh 23 days ago [-]
Yes, this is more or less what RFC 1178 recommends:


23 days ago [-]
jaggederest 23 days ago [-]
For some reason nobody liked my norse pantheon names.

Teaching people to spell yggdrasil correctly in order to get a database connection is fun. For some values of fun.

pure-awesome 22 days ago [-]
Dwarf Fortress values of Fun.
rileymat2 23 days ago [-]
I am not understanding why the machine name could not be changed when it's purpose changed? Is an immutable name unique to that environment?
tolien 23 days ago [-]
Because you'd probably also change the SMB or DNS name for the machine when you rename it, and that opens a can of worms where you try to work out what's using that reference and change everything that matters.

Now renaming the machine is a multi-day thing involving configuration changes (and that assumes it's not hard coded anywhere) to a whole bunch of software; inevitably you'll miss some and it'll break. Easier not to bother.

cortesoft 23 days ago [-]
If something else is still referencing the old machine, it means you aren't changing its purpose but only adding to it. I would imagine a change of purpose would normally be a reprov.
jolmg 23 days ago [-]
Changes can be gradual. I know a server that was named after a single service the machine was set-up for. Then later across a span of time, more services needed to be added. They're unrelated services, but circumstances necessitated them being installed on this server. Then even later, the original service ceased to be used and was shut-down.

Changing the name might imply changing references in other services that make reference to this server for the current services that are still running. It might also imply changing bookmarks in the machines of the users of the services still running on this server.

The bookmarks are a concern because many users don't know how to do anything with bookmarks other than clicking on them, so you can't depend on them understanding how to edit the URLs of these bookmarks. Yes, that's depressing.

teddyh 23 days ago [-]
RFC 1178 answers this:

However, let me add that if you later decide to change a name (to something sensible like you should have chosen in the first place), you are going to be amazed at the amount of pain awaiting you. No matter how easy the manuals suggest it is to change a name, you will find that lots of obscure software has rapidly accumulated which refers to that computer using that now-ugly name. It all has to be found and changed. People mailing to you from other sites have to be told. And you will have to remember that names on old backup media labels correspond to different names.

23 days ago [-]
xorcist 23 days ago [-]
It is a good idea not to re-use host names. Otherwise you may encounter soft fails if the old name is still accessible, especially in systems outside of your control. If there are certificates generated it will also guarantee that they can not be re-used. So it is a good rule of thumb in larger organizations.
kristopolous 23 days ago [-]
Names are an opportunity for fun. Call that old server PersistentSnail, or some old fashioned name like Myrtle. Make naming a reason to smile.
bluedino 23 days ago [-]
The only machine we have that's not named poorly, is named DP2950. It was originally a Dell PowerEdge 2950, and we probably had more than one back then, so maybe it wasn't a great name.

Everything else is named based on it's purpose.

www, webapps, data, acccounting, mail, things like that.

But, mail is actually named mailV3 (it's the third hardware the mail server has been on). Why it wasn't just named mail, and if the old one was kept around, it could be mail-old, I don't know.

Then we have our development servers. devel, develv2, www-devel, that kind of stuff. I'd personally prefer devel-whatever the name of the production version is called. Instead we have to thing 'develv2 is actually the development version of dp2950....'

inimino 23 days ago [-]
> Why it wasn't just named mail, and if the old one was kept around, it could be mail-old, I don't know.

Probably because mail system hostnames end up hardcoded in configuration files all over the place, and it's easier to add one and mirror onto it than to migrate the hardware while keeping the name.

grogenaut 23 days ago [-]
I find that team names change more frequently than responsibility in a large org. Also using a team name makes people assume ownership of decisions with that team. That's why I prefer service name. However I haven't thought much about shared use clusters.
neilkakkar 23 days ago [-]
We've had the same name for the past 7 years, so going by the future estimates with no extra useful information, I expect us to have the same team name for 7 more years :P
grogenaut 23 days ago [-]
Makes things easy for you then. My company, every manager hire decides to change team names. Had a vp who used to be marketing that changed the org name like 4 times in 2 years. Cause name changes fix everything. Essentially we have a few teams / orgs with name of the week.
dotancohen 23 days ago [-]

  > Nobody expects to learn much about a person by their name.
This is wrong. If I tell you that I just hired a mathematician, a farmhand, and a nurse, you could probably guess which person was which when I introduce you to Vladimir, Jebbediah, and Sofia.

Names are a reflection of culture, and certain cultures tend towards certain professions. No politically-correct dreams will change that unless we instill a universal monoculture throughout the world. I'm sure that Disney and Coca Cola would love that, but most people would probably prefer to protect their heritage and culture.

teddyh 23 days ago [-]
> Names are a reflection of culture, and certain cultures tend towards certain professions.

They key word there is “tend”. Since it’s not an absolute, it would be unfair and ultimately disadvantageous of anyone to pre-judge individual people based on their name, since it is not a guarantee.

username90 23 days ago [-]
Branch prediction is a very good optimization though, you'd lose quite a lot if you forbade people from using it.
teddyh 23 days ago [-]
> you'd lose quite a lot if you forbade people from using it.

We do forbid it, though: https://en.wikipedia.org/wiki/List_of_anti-discrimination_ac...

It seems that we have decided as a society that we gain more from the cumulative effect of all people gaining a equal and fair chance, than we would save by allowing people to use whatever branch predictors they like.

It looks like branch predictors in general tend to have unforeseen problems; see also https://en.wikipedia.org/wiki/Spectre_(security_vulnerabilit...

m90 23 days ago [-]
I think your example rather exemplifies what kind of cliches "Disney and Coca Cola" have established. This kind of role models is the universal monoculture, not a nurse called Vladimir.
wool_gather 23 days ago [-]

- Dr. Sofia Cerny, the brilliant Czech topologist

- Vlad, a fifth-generation Ukrainian dairy farmer


- Jeb, a favorite of the patients at his clinic, who is not on speaking terms with his Southern Baptist pastor father

pure-awesome 23 days ago [-]
> It is especially tempting to name your first computer after yourself, but think about it. Do you name any of your other possessions after yourself? No. Your dog has its own name, as do your children. If you are one of those who feel so inclined to name your car and other objects, you certainly don't reuse your own name. Otherwise you would have a great deal of trouble distinguishing between them in speech.

a) I am, in fact, named after my father.

b) This does, indeed, cause trouble for other people trying to differentiate us.

teddyh 23 days ago [-]
“We named the dog ‘Indiana’!”
paulsutter 23 days ago [-]
Like the inevitable branch names. Main, Borg, Borgmain, etc... Or the purposes of the standard unix directories (lib, usr, opt, etc, ...)
galaxyLogic 23 days ago [-]
Isn't Cloud-Computing something that should make it unnecessary to name individual computers?
pmiller2 23 days ago [-]
How do you make a service call or ssh into a machine without a name?
scarface74 23 days ago [-]
IP Address. We have “servers” that get created and destroyed nightly based on how many items are in the queue. All of our web servers are behind autoscaling groups. Even the ones where we have a min/max of 2. If it doesn’t respond to a health check it gets killed and another one is brought up.

Ideally, none of our servers are special.

Ao7bei3s 23 days ago [-]
You don't. Stop thinking in machines.

Your code doesn't directly call a service, you'd use a service discovery framework (eg AWS Cloud Map) to lookup a location that can handle a particular type of request. It doesn't even matter to the caller whether the request is handled by an instance (eg EC2), a container (eg Fargate), or a function (eg Lambda).

End user requests are handled by an application loadbalancer (eg ELB) that accepts the requests and routes them to an available location, which again doesn't need to be any particular machine (and it can also spawn/destroy instances as needed) or type.

With serverless computing (eg AWS Lambda), there's not even machine for you to SSH into, the cloud takes care of executing functions "somewhere" to handle your work. Work could mean serving an HTTP request - however there doesn't even need to be a client making a call; the lambda could e.g. run in response to an event on an S3 bucket.

Of course AWS can also handle your pets; ie you can name your EC2 instances (and either manage DNS outside, or use Route 53 to let AWS handle it). But that's not what AWS is about; there are way cheaper options for vServers. And of course there are real computers below this, and DNS is being used in the middle of this (with auto-generated names that you don't care about). But you don't deal with that.

pradiptasarma 23 days ago [-]
Why is this downvoted?
jedberg 23 days ago [-]
The first thing you should do is question why you're SSHing into a production server in 2019. But after that, usually you can do it by IP address or instance ID.
maccard 23 days ago [-]
OP never mentioned it was a production server. Also, sometimes, things get stuck, or you haven’t set up a pipeline to gather X data but y has happened, or there’s a deadlock in your source control host, or you’ve accidentally deleted the backup and the live service is the only copy of the data... all awful reasons and yet I’m sure they happen every day to people.
jedberg 22 days ago [-]
I didn't say you should never ssh into an instance, I just said you should ask yourself why you're doing it first. Every one of the reasons you listed is a great thing to be cognizant of so that you can make a list/ticket/whatever to fix that problem so you won't need to ssh again to solve that problem.
neilkakkar 23 days ago [-]
Haha, I had no idea. Thank you!
rootusrootus 23 days ago [-]
At the last place I worked at (a smaller ISP) we were a little spastic with our naming schemes. Sometimes boring -- web-1, web-2, web-3, web-4, ... and sometimes more entertaining -- we named a cluster of content filtering servers after porn stars (sindee, etc).

Now everything is a VM so I'm back to naming "servers" by their function because I don't really need to worry about them being multifunction or evolving.

lonelappde 23 days ago [-]
It's sad to see in the current century that a group of erstwhile professionals jump to "porn stars".
rootusrootus 21 days ago [-]
Some folks are more relaxed than others. I have even seen servers named after gods in the distant past, can you imagine? Try naming a server Odin now, or Loki, etc. Used to be a popular naming scheme but today it would have someone complaining to HR about inappropriate religion in the workplace.

I gotta say that whoever flagged that post has the thinnest skin I've yet encountered. Even for HN, I am slightly surprised.

esotericn 23 days ago [-]
For servers that, er, probably filter out porn stars?

You realise someone has to do this stuff, right?

pbourke 23 days ago [-]
Why is this being downvoted? It is highly inappropriate to do this in a work context.
flukus 23 days ago [-]
Because it's like having subtle adult jokes in Disney movies, the adults get it and the children are oblivious and unharmed by them. Anyone offended by the use of porn star names wouldn't (or at least shouldn't) know what it's referencing.
enneff 23 days ago [-]
I know that porn is pretty normalised by western culture, and I’m not reply anti porn myself, but if you can’t see how another adult might find porn references in their work inappropriate then I don’t know what to tell you.
rootusrootus 21 days ago [-]
Heh, 9 out of 10 people couldn't even tell you where those names came from. They never even had a chance to be offended. And frankly, not too many people wandering through the datacenter spent much time reading all the labels.
dragonwriter 23 days ago [-]
> Anyone offended by the use of porn star names wouldn't (or at least shouldn't) know what it's referencing.

“Offended by the use of X to name servers at their workplace” doesn't imply “have never heard and wouldn't recognize the names of X”. Whether X is “porn stars” or “Nazi leaders”.

arpa 23 days ago [-]
I'm naming my server Godwin.
rootusrootus 21 days ago [-]
It is somewhat amazing how reliable that rule is. A part of me wonders how many people actually do it on purpose.
Joof 23 days ago [-]
Maybe. But they were doing web filtering, so I get it.
arpa 23 days ago [-]
Some people work in porn hub, and some in the mormon church. Of course the culture will differ. I, personally, would rather work for the pornhub than the mormons purely due to ethical reasons.
pbourke 23 days ago [-]
The example that cited upthread (a smaller ISP) had nothing to do with either of those examples, which are both extremes in terms of corporate culture.

Naming your servers after porn stars is the digital equivalent of having pin ups in your auto shop. Can you not see how this creates a hostile work environment for some employees? It’s inappropriate, unprofessional and unnecessary.

I shouldn’t even need to footnote this by saying that I don’t care whether someone enjoys porn in their personal life. If the business is not about porn, porn shouldn’t be a topic in the business.

arpa 23 days ago [-]
Again, it is a matter of workplace culture, that is, the collective understanding of what's ok and what's not in that particular workplace. If everyone's ok with having pornstar names for servers, fine, whatever rocks your boat. I'm for diversity of workplace cultures instead of bland corporatism "safe space" and samethink. And besides, ain't nothing wrong with pinups in the autoshop as long as they do not discriminate them by gender, color and age :)

Peace & chill.

zo1 23 days ago [-]
It's downvoted I guess because it's inflammatory and causing conflict/political discussion where there was absolutely none. I.e. We're talking about something innocent like naming servers.
rootusrootus 21 days ago [-]
It got as many upvotes as downvotes, actually.

People also name servers after Norse gods, which might be offensive to religious folks. Many naming schemes are not innocent unless you just aren't offended about the particular topic. Here's the thing, though -- once we decided that the metric was whether or not someone could be offended by something, then we made everything offensive. Whoops!

amzans 23 days ago [-]
> Good engineers themselves design systems that are more robust and easier to understand by others. This has a multiplier effect, letting their colleagues build upon their work much more quickly and reliably - How to Build Good Software

The advice above is probably one of the things which would have the most impact across all your activities as a developer. When people talk about simplicity in software, they don’t necessarily refer to ease of use or number of lines of code, but instead it’s about how understandable a solution is given their shared knowledge.

dxhdr 23 days ago [-]
> When people talk about simplicity in software, they don’t necessarily refer to ease of use or number of lines of code, but instead it’s about how understandable a solution is given their shared knowledge.

Rich Hickey gave a great talk on the topic of "simple" vs "easy": https://www.youtube.com/watch?v=rI8tNMsozo0

atoav 23 days ago [-]
This is also good advice for other areas, even if you are 100% sure you are the only person to ever lay their eyeballs on what happens behind the curtain.

I worked in VFX and film post production and this spirit usually saves yourself a lot of hassle in day to day actions and even more so if you get ill, can’t do the job anymore or decide to split it up.

The way I worked in VFX certainly had a big impact on my programming. Some work ethics just make sense.

jiveturkey 22 days ago [-]
> most impact

by far. What's missing is:

> easier to understand by others.

And by yourself, 6 months later.

Anytime a "senior" dev complains to me about "junior" devs, I tell them to review their own code from 6 months ago.

Everlag 23 days ago [-]
The referenced idea of a 'human log' is great[0]. I started doing something similar 4 years ago and it eventually evolved from per-project notes into a full diary. Being able to search for 'August 24 2016' and know exactly what I did that day is quite powerful.

I encourage anyone to take 10 minutes(or 30...) at the end of the day to write up what they've done. Just a text file with minimal formatting has scaled to 2.6MB of hand-typed text. Though, after a bit, I've tended to shard out specific long-running topics into their own files.

[0] https://neilkakkar.com/the-human-log.html

mikekchar 23 days ago [-]
I have an admittedly crazy thing I do occasionally. I do 5 minute pomodoros. So it's 5 minutes of writing code followed by 1 minute of reflection. In that one minute, I'll write down what I did in the last 5 minutes (it takes about 10 seconds to write since it isn't much ;-). I'll also add a few TODOs that I'm hoping to do, or break down ones I've already got.

Now, 5 minutes seems an impossibly small amount of time, and admittedly this is a difficult technique. It's also very tiring (I can't do it day after day), but once you get good at it, it's surprising what you can get done in 5 minutes. You don't necessarily need to have written code -- just made some progress towards understanding something, etc.

Later, I'll go over my notes. I've got everything annotated every 5 minutes which means that it's ripe for thinking about how I can improve. Did I make a wrong turn somewhere that wasted me time? Was there a way I could have detected that? Did I decide not to do something test first when it would have been better to do so? Etc, etc.

I should point out that while I have a timer, I only use it as a suggestion -- I don't have any notifications for instance. It's just that if I glance down and notice my timer has gone (or is close), then I wrap up what I'm doing to get to the reflection stage. Similarly, if I'm writing TODOs and it's being productive, I don't mind doing it for 5 minutes or so. Finally, if I run into something really puzzling, then I just turn off the timer. Some problems need thinking time (though I have found that having only a few minutes to make progress often forces me to try something in order to get more information and that will crack the nut -- indeed, far more often than I would have ever suspected).

It's the only tool I've found that really helps me improve my technique. The other pretty cool thing about it is that I've found that this log helps me get in and out of the zone extremely quickly. Even if I've put it down overnight, I'm right back into it within a minute or so.

I am measurably much more productive with this method (like 2 or 3 times more productive), which surprised me initially (I thought I would be much less productive). The real downside is that it's draining. I can't keep it up for more than a couple of days at a time.

Anyway, very dissimilar to what you were talking about, but I highly recommend it for those interested understanding what they are doing and how to improve.

Doubl 23 days ago [-]
If you're 2 or 3 times as productive for a couple of days then you can easily afford to take a day off. How much downtime do you need before you're able to repeat the pattern?
mikekchar 22 days ago [-]
Yeah, a day off is definitely enough... It's a good point. I need to start doing fix cost contracting.
crucialfelix 23 days ago [-]
I like this idea. I had private Twitter style note taking set up for a while for the same purpose.

I currently journal my day at the end, noting when I worked on the wrong thing and why.

It would be interesting to record the screen for a whole week day and then review and annotate for insight.

Some day traders used to do this. Athletes do it all the time.

newshorts 23 days ago [-]
This is really interesting. I’m going to try it.
isoprophlex 23 days ago [-]
This sounds revolutionary, I'm going to try this! Thanks for sharing.
mtlynch 23 days ago [-]
I do this on a weekly basis. I used to just do it in a Google Doc, but earlier this year, I wrote an app so I could share my log entries publicly. I've been publishing my weeks since March:


I tried for a few months to make a business out of it, but there wasn't much interest, so I'm planning to open source the code in the next couple weeks.

A bit more about my motivation in creating this: https://mtlynch.io/status-updates-to-nobody/

neilkakkar 23 days ago [-]
This is awesome (and lots of projects - I love it!)
yitchelle 23 days ago [-]
This is really good. It reminds me of a bullet journal. Well done!
satysin 23 days ago [-]
Indeed I have been doing this for all my work for over ten years now and it is one of my favourite things.

I use Day One as I also use it for my personal journal. Plain text is great but I do like being able to add rich content (screenshots for example).

As you say being able to look back and know exactly what you were doing on a particular day is a powerful thing.

I've found that over time I have become a lot better at succinctly explaining the problems I faced and how I made progress with them. It is invaluable, even just over the weekend, in helping me 'reload' my brain when I return to work. It also helped me in communicating more technical subjects to others less technical.

It's a brilliant way to unwind and finish the day. I usually only have to spend 5 minutes on it so it isn't like it is a huge commitment.

I highly recommend everyone at least give it a go for a month and see if it works for you.

ThrowawayP 23 days ago [-]
And what does one do when one is struggling with burnout/depression/insomnia and the only legitimate thing to write down is "Not a whole lot really." for days in a row? (A problem a um, ... friend has, of course.) Risky habit to have under those circumstances.
JohnBooty 23 days ago [-]
That might be the best time to take up this habit.

Write down everything you do and honor it as an accomplishment.

Getting out of bed. Reading an article about your craft. Brushing your teeth. Showering. Dressing. Reading somebody else's PR. Commenting on somebody else's PR.

Every. Single. Thing.

Attending a meeting. Having a hallway conversation. Answering an email or ten.

Not taking your own life. Surviving. Not doing other self-destructive things.

Chances are, if you are able to get out of bed (not always a given) you probably did a lot of "little" things. Those are achievements. And in your depression those things may have taken more effort than running a 5-minute mile.

Sure, the goal is to eventually accomplish more. That's fine. But honor the things you're doing.

And hey... good luck.

taftster 23 days ago [-]
I think that's still a valuable log entry. You should be able to look back at your log and see the periods of inactivity, possibly being able to identify or correlate the time associated with other life events. Maybe you can work on finding ways to identify and exit those periods sooner.

I believe everyone has times of marginal productivity in their lives, maybe some more than others. But if you can average out ahead of the curve, what does it matter? Showing the fact that you've had a slow week but finished the month on a high note seems like a great capability.

And if an employer doesn't recognize this and can't measure your net output, then hopefully another employer can.

tiglionabbit 23 days ago [-]
Then the journal could help you notice the problem and take action sooner.

I've had a lot of stress at work. Here's how I dealt with it:

I was once working for a boss who was really infuriating to deal with. To prevent myself from exploding at him, I would take a break, step outside in the beautiful sunlight, put in my earbuds, turn on some good music, and run. I channeled my frustration into exercise. I'd especially make a habit of doing this just before I ate lunch, which would stimulate muscle growth and make me happier and healthier. Somehow that stressful job got me into great shape.

I was once working at a place where all the policies were dysfunctional and things were constantly on fire. I dealt with this by pulling out my phone and using the Headspace app to think about nothing for a moment and calm myself down. When I got back to the work, I'd put on some "focus" music (music for programming, studying, etc) that would help me maintain my calm mood when implementing the fixes. I learned to distance myself from the problem and get people to talk to each other to work it out instead of having proxy arguments on other peoples' behalf.

I've had some pretty bad sleep problems as well. I got into the habit of playing videogames late at night, which really destroyed my sleep. It's really hard to sleep right after staring at bright screens and experiencing intense action. Now I have F.Lux or Night Shift enabled on all my machines and I avoid playing console games at night without wearing yellow safety glasses. Also, I've started adding concentrated lake water to my drinking water since a magnesium deficiency can make it difficult to sleep.

For depression, perhaps learn about Taoism?

If you really can't cope with the job, quit. It'll be even more stressful to try to find a new job while you're already working one. You can search for a new job using TripleByte, which saves a lot of time since you just have to do one coding test instead of 20.

Hope this helps. Good luck.

Aeolun 23 days ago [-]
In that case I guess you should start writing down the 3 good things for that day. Helped me, and it’s fairly positive, even if what you end up with is a string of: ‘Made it through another day’ entries.
Haydos585x2 23 days ago [-]
When I'm in that sort of space I just write down really trivial things in my "Today List". I've been sick for a few weeks so my tasks have been: "have a shower", "make a coffee", "take a nap". I don't know if it would help with more severe cases but it at least lets me feel like I'm moving along. You probably completed a few distinct tasks you could write down.
Everlag 23 days ago [-]
I've been there, I've got a bunch of entries that summarize to 'Bleh day'. For me, though it may differ for others, those entries are useful. They let me notice that something is off and help me figure out if there's a pattern.

I completely agree with taftster in a sibling comment.

cjnicholls 23 days ago [-]
It may be more useful in that case to increase frequency of contributions to the log which will change your objectivity when logging. You may be missing all the small contributary things that lead to achieving a bigger task soon after.
mikekchar 23 days ago [-]
I've had burnout a few times in my career. I think it happens to anyone who really enjoys their job. It's like being placed in front of a pile of candy -- just one more piece!

But burnout is an awful feeling. You aren't able to work. For me, I would stare at the screen for hours on end without being able to get started.

I found that 2 things helped me the most. First the pomodoro system. You are probably familiar with it, but just in case: you have a 25 minute session, where you devote yourself to nothing but concentrating on work. For me, it's unbelievably important to get my first pomodoro in as early in the day as possible. I also found that it is just as important that this pomodoro is coding: not reading mail. Not doing a status update. Not having a standup meeting. Not investigating some bug. I've got to write code as soon as I can in the day. That flips a switch for me. Very important, especially if you are burned out: show up for work significantly before your fist meeting of the day -- the meeting will suck the life out of you and you need some life to suck.

The next thing, strangely, is a TODO/log of what I'm doing. Being burned out means that everything is a barrier. Usually the barrier is too high, so you are stuck staring at it with no idea how to get over it (because normally you would just step over it).

When I first start a pomodoro, I write a TODO of what I'm going to do for the next 25 minutes. I find it's best to spend as little time as possible doing it. Just write down the first thing that comes to your mind about what you need to do. Write 3-4 items at least. Then start tackling the first one. Inevitably, you will find that your TODO was not good -- because you didn't spend time thinking about it. As soon as you realise what you need to do, update your TODO and then do it.

It's tempting to write the code and then write down what you did. I find that it works best to do it the other way around even though it breaks the flow. When you are burned out, flow is quite hard to maintain and any distraction is going to grab you hard. By focussing on making sure your TODOs are correct, it means that you can easily jump back in.

The biggest thing to realise is that you will often be punted out of the zone and will be staring at your screen. What you need to do is to say to yourself, "Just one more" -- which means, making an easy TODO for yourself and writing the code to fullfil it. Then "Just one more". Eventually you will get distracted. When you finish being distracted, turn on the pomodoro timer and say, "Just one more".

At first you may find it hard to do more than 4 pomodoros in a whole day. Don't worry about it. Just try to do as many as you can. Then the next day try to do more than the previous day. I have found that I can claw my way out of burnout pretty quickly like this. It doesn't take long before I'm enjoying my work again. After that, the productivity starts coming back and things start to feel easy again.

Hope this helps.

neilkakkar 23 days ago [-]
Indeed! Thanks Everlag!

I think it's been the top productivity hack in my life.

Not only did it help me keep my thoughts in check, but it became a solid base for me to bundle other habits on top. If I keep a daily log of stuff (one I look forward to because it's super useful - not just a calendar) , all I have to do is add a new column for a new habit I'm tracking, and everyday I'm forced to put in a Yes or a No, which then snowballs into the "Don't break the chain!".

aizatto 23 days ago [-]
I created something for myself to use https://www.logbook.my

I can both back date and future date entries.

I keep a tag called "Daily Entries" with a timestamp on the day of what I use, I can automatically add a timestamp with the shortcut "CTRL + T"

Future dating allows me to plan ahead as well.

I write an entry about a future event (ie a meeting) and prefill some information. Then when the meeting happens, I just open up the entry and start entering.

I've been using Logbook since 1st May, and personally now have 1139 entries, and 576 tags.

I've been recording:

- Recipes - Meeting notes - Shower Thoughts - Career timeline - Car maintenance - "Best Practices" on a variety of subjects - Many more

I also use timestamps a lot, and have a preference for how they are formatted so I created https://timestamps.aizatto.com

I hope some of these may help people here

acemarke 23 days ago [-]
Yeah, I've been doing this since the start of 2013. Last thing I do each day along with filling out my time card.

I usually recap what I worked on, conversations I had, other project / teammate updates, where I left off, stuff I learned or fixed, and where I need to pick up the next day.

I used RedNotebook for the first few years, then switched to Boostnote because of its Markdown support and snippet syntax highlighting. One note per day, organized into folders by month.

It also is hugely valuable when performance review season rolls around. I can go through the whole year in a few minutes and remind myself of all the tasks I worked on, then summarize those in the "what I did" section.

JustSomeNobody 23 days ago [-]
I started paper logging when I got my first programming job. At first it was just to write down things I needed to know; IP addresses/host names, bugs I worked on, etc. Eventually, I started logging more information about my thought process for why I designed something a certain way or how I tracked down a bug. These come in handy months later when the bug comes back and I can refer to my notes and talk to the team about it, or when I need to design something similar and need to give an estimate. Are there better places to put this? Sure, I guess, but this is mine[0] and I can write down what I want.

[0] Oh, in case anyone is curious. My logs stay with the company when I leave. I don't take any IP with me.

jrochkind1 23 days ago [-]
Exactly what a traditional scientist's notebook is.
bspammer 23 days ago [-]
I've been doing this for the last few months, along with taking a picture every day and attaching it to the text. I've found it has noticeably improved my short-term memory of events, which has always been a weak point of mine. I imagine it will also be a nice time-capsule to look at in 40 years.

I'd really encourage anyone to give it a try.

nevster 23 days ago [-]
I kept a paper journal for work for years. I finally decided to go digital for search-ability and investigated all sorts of things like Day One, etc.

Ended up just adding a new "Work Journal" calendar to my google calendar.

noonespecial 23 days ago [-]
I was already forgetting things I learnt. They either became so internalized that my mind tricked me into believing I always knew them, or they slipped my mind.

The best time to write a tutorial is as you learn a thing yourself. You learn it better for doing it and others benefit from it more because it automatically comes from a beginners perspective.

caymanjim 23 days ago [-]
> I like a bit of humour in my code, and I wanted to name it GodComponent.

No. Just no. Do not ever be funny in code. No one else likes your humor, and it's distracting. (Ignoring the other reasons "GodComponent" is a bad name.)

cwbrandsma 23 days ago [-]
I needed to wrap the code that handled thread management that I use in Swift. I called the component Threader, and in the comments I mention I named it after the TMNT character Shredder.

Two things came from that: I have gotten a chuckle from all the developers I introduced to that code, and no one has forgotten about it.

Some humor is useful.

xmprt 23 days ago [-]
That's nice when the team is small and everyone knows what the code does, but when new members start joining and you have all these inside jokes/references all over the code, it becomes more cumbersome than anything to explain what it is. I enjoy humor but keep it to a minimum and hopefully don't impact the actual readability.
mattkrause 23 days ago [-]
The trick here (and in someone else’s “Thrilla in Mozilla”) is that you don’t need to understand the humor or reference to understand the code. It’s just a nice little bonus, since threader is already a perfectly reasonable[0] name.

This is different from insisting that helper functions in brains.c be of type pinkyfunc_t.

[0] I was tempted to undercut my own point and write cromulent there instead.

askafriend 23 days ago [-]
Meh, I don't value that opinion at all. Especially a hard-line stance of "DO NOT EVER".

I'm going to continue injecting some light humor into my code and it'll be fine (especially unit test code).

gumoro 23 days ago [-]
Yes! Unit test code!

I avoid humor in main code, but in unit test code when you have to come up with dummy bits of test data or variable names, I love getting funky there :)

philwelch 23 days ago [-]
I think it's okay to be funny in test cases. For instance, my test data has included the user-agent string, "The Thrilla In Mozilla".
caymanjim 23 days ago [-]
I think this kind of thing is fine; you're not talking about functional code, just placeholder text. I have no problem with humorous names in strings for simple test cases, where no one would ever search for it, and it has no real meaning. I've done the same sort of thing myself plenty of times.
dgritsko 23 days ago [-]
I've certainly read apocryphal stories (perhaps on HN, can't remember) about offensive data being used in test cases "as a joke" and due to a variety of reasons having that data end up in production systems (visible to customers). I'm all for a bit of humor, but it's worth thinking about the issues that might be caused were your fake data to wind up on a production site.
philwelch 23 days ago [-]
I wouldn't use offensive humorous test data, but using obviously fake humorous test data makes it easier to detect and mitigate those kinds of situations. If for some reason I noticed that all of my production data came from an obscure browser that called itself "The Thrilla In Mozilla", that would be a lot more noticeable and easier to correct than if my test user-agent string was just Chrome or whatever.
jchook 23 days ago [-]
As long as you don't go into potentially offensive humor
jmpeax 23 days ago [-]
Isn't there like a law or razor or something named after someone that says all humor will one day be offensive?
mindcrime 22 days ago [-]
If not, there probably should be.

"Jmpeax's Law" doesn't really roll off the tongue though...

lonelappde 23 days ago [-]
Upthread we have someone boasting about naming their business machines after porn stars.
lacampbell 23 days ago [-]
Why does that bother you so much?
jchook 23 days ago [-]
I had to learn the hard way
Moru 23 days ago [-]
I worked with home support for an ISP. A few times I was at a customer helping with a router and the mother call her son to get the password for the router. Not always a nice password...
philwelch 23 days ago [-]
I very much believe in offensive passwords/passphrases (maybe not for wireless routers) specifically because:

(a) You're not supposed to tell anybody what they are.

(b) Offensive passphrases are easier to remember.

ses1984 22 days ago [-]
Also easier to crack if an attacker knows that detail.
philwelch 22 days ago [-]
Not that it narrows it down that much.
ses1984 22 days ago [-]
You could probably throw out 90% or more of dictionary words for your permutations, I'd say that is significant enough to paint a target on your back.
philwelch 21 days ago [-]
If your password is derived from a four word phrase (per the XKCD formula, which isn’t the only one), potentially all of the individual words could be inoffensive in isolation. There’s no obvious way to operationalize the human intuition of offense in a way that restricts the search space if you’re smart about it.
ses1984 21 days ago [-]
It all depends on if you have anything worth cracking. Sure, if your average hn reader encrypts a password db with a dirty four word phrase, that reader will be fine because no one is willing to rub two pennies together to crack that.

On the other hand if you're protecting secrets actually worth something...

philwelch 20 days ago [-]
Hey, for all you know I might find certain seemingly random 128-character alphanumeric strings very offensive ;)
ses1984 20 days ago [-]
Seemingly random isn't random.
GrayTextIsTruth 23 days ago [-]
why not? best kind of humor
mikekchar 23 days ago [-]
I do work for a golf travel company. In my test code I have the fictional golf resort, "Fine UK Up-scale Resort", due to the way we sometimes abbreviate names. I was doing a presentation to management the other day, and which test data decided to pop up on my screen? I laughed, anyway... I don't think some other people were please ;-) Especially as a contractor, making sure management is pleased with you is normally job one...
newshorts 23 days ago [-]
I agree on the aspect of professionalism. I wouldn’t go so far as to say never. Maybe there is some situation out there where it’s appropriate and understandable. I’ve just never seen it ;)
WatchDog 23 days ago [-]
I for one appreciate good humour in a codebase.
lonelappde 23 days ago [-]
Ah, but do you appreciate bad humour?
WatchDog 23 days ago [-]
No not really, but I also don't appreciate bad code, and I encounter a vast amount more bad code than I do bad humour in the course of my work.
nojvek 23 days ago [-]
I mean you can be plenty funny. Just not in naming things. My elaborate rants as comments on some parts of system have a bit of humor or sarcasm in them. I guess it’s a team thing. Our codebase has been built over time and has a number of hilarious comments.
pradiptasarma 23 days ago [-]
Exactly, the following is fine:

  try {
  } catch (Exception up) {
    throw up; //hehe

The GodComponent as a name is not.
PopeDotNinja 23 days ago [-]
I enjoy seeing a bit like of humor in the code, especially silly-but-clear comments and names less important parts of code. For a one shot task, why name it ScheduledObjectStorageDownloader when you can name it AutoCloudStorageFileYoinker?!
OJFord 23 days ago [-]
Because someone might grep for 'schedule' or 'download' but, quite reasonably, not think of 'autocloud' or 'yoink'?
richardxia 23 days ago [-]
While I'm not 100% against humor in a codebase, ever since my company started hiring more engineers internationally, I've become more tuned in to whether a name that uses slang like "yoinker" will be understood by someone who doesn't know English as a first language.
sundvor 23 days ago [-]
I've been using English as my first language for nearly 20 years and am unfamiliar with "yoinker".

Just googled it and, ... nah, I wouldn't approve that PR!

(Have never heard it used down here in Australia. We've got plenty of other sayings that are local to us though.)

PopeDotNinja 22 days ago [-]
Hehe, I never googled yoinker until just now. I originally heard it on The Simpsons. Here's a SFW Simpsons supercut of "yoink":


I suspect there are a lot of words that used to be safe that are less so now :P

PopeDotNinja 23 days ago [-]
That is a fair point.
jpz 23 days ago [-]
100% with you on this. I find the replies to your comment here remarkable.

Namings should be descriptive not idiosyncratic.

It might be just like the guy I spoke to last month that said he just makes everything public when writing Java. Some people can have opinions that differ from best practice, it doesn't justify them, however.

Express your personality when you speak to people face to face, tell a joke, make witty observations at lunch, or in a code review meeting, don't express your personality in manifest idiosyncracies in your comments and code.

mawburn 22 days ago [-]
I used to name projects of funny names, but then I started realizing that I had no idea what other people's cute names were for their projects.

We have one in our company named right now named Harbinger, neat name... but wtf is it? Boring names are boring, but they tell other people, and future you, what they are or do.

paxys 23 days ago [-]
Yeah, seriously. People use the "it was just a joke" argument for so many stupid things. Realize that there are people here whose sense of humor is very different from yours and this inside joke is likely going to cause confusion or conflict.
heinrichhartman 23 days ago [-]
> When refactoring and preventing huge-ass PRs: “If I’d have changed all the tests first then I would have seen I had 52 files to change and that was obviously gonna be too big but I was messing with the code first and not the tests.” Is breaking it up worth it?

My 2 cents: There are two things to consider:

1. reviewability

2. deployment risk

If it takes a colleague 3 days to review your code, your PR is too big. If you panic, on the thought of deploying this ever, your PR is too big.

On the other side:

- Huge PRs that only change formatting are fine. Easy review. Low risk if properly automated/tested.

- Largs PRs that are feature neutral are acceptable as long as they are reviewable.

- PRs that refactor 2000LOC, fix 2 bugs and add 3 features are not a good idea.

foobarian 23 days ago [-]
There are certain ways to organize large PRs to make them easier to review and deploy. Some examples:

- if a large refactor moves code around in addition to changing logic, omit the pure moves from the diff and provide a list of files moved in a description

- if a large refactor involves a lot of renaming, or other mechanical manipulation, in addition to a little bit of logic changes, split those apart. That way there will be one large mechanical diff, where you can state in the description, "Yes I changed 500 files and there are 20 pages of diffs but the nature of changes is the same as in the first file." This is vastly easier to review for your peers.

- A useful safe deployment trick, when feasible: guard new functionality with a kill switch, as well as some kind of sampling gate (e.g. use new logic only where customer id % 31 == 0). Then when proved remove old code in a followup.

einpoklum 23 days ago [-]
The thing is:

1. Some people balk at you making lots of small PRs, because it feels like noise to them. 2. Some people/organizations make you do a lot of work on a separate branch and then want you to PR just once for the final feature you're implementing.

lonelappde 23 days ago [-]
1. Commits can be merged/squashed when merged upstream.

2. That's fine, your branch has the series of small PRs that people can review.

honkycat 23 days ago [-]
Just to toss in my two cents about testing:

Unit tests are for refactoring and declaring behaviour. Additionally, a lot of people have made the same observation: Code that is easy to unit test tends to be more modular and have better architecture. If you are struggling to test a function, think about how you can change your design to make testing easier. It will probably improve your code quality.

Integration tests are for finding bugs and exceptions and should be a part of CI/CD.

You want both. The more testing the better.

Comments: I find comments, outside of docstrings, a smell. Even then: Docstrings often become a substitution for a decent type system, so maybe think about what is happing there as well.

Documentation should be generated from your codebase. Otherwise, it will inevitably become out of date as people forget to update it. If you need to comment on what something is doing, usually you can move that behaviour into a function and test that function.

heinrichhartman 23 days ago [-]
I have heard this so many times:

> Comments: I find comments, outside of docstrings, a smell.

But is this really the case? I find comments like these invaluable:

      * Mark walreceiver as running in shared memory.
      * Do this as early as possible, so that if we fail later on, we'll set
      * state to STOPPED. If we die before this, the startup process will keep
      * waiting for us to start up, until it times out.


Part of the job of a developer is to communicate

- domain model (Concepts, Relations between them)

- intention behind the code (Why is this code here?)

- possible pitfalls (I tried this, it does not work because ...)

- limitations (TODO: This special case does not really work, yet)

for your colleagues and future heirs.

How would you ever cramp information like this into variable names and types? (... without introducing so much abstractions that the code becomes unreadable).

honkycat 23 days ago [-]
This is EXACTLY where comments should be used, great example!

Extremely high-performance database code is not what most of us are doing, however. We are doing enterprise software development to send emails and scrape money out of people.

I would want that function to be multiple smaller functions with docstrings and such, but obviously, that would add stackframes to the call stack and be slower.

Additionally, many modern compilers have an easier time reasoning about and optimizing multiple smaller functions as opposed to huge functions with a ton of variables and logic. Plus large functions have an impact on garbage collection etc. etc.

heinrichhartman 23 days ago [-]
> Extremely high-performance database code is not what most of us are doing, however.

That's true. But look at the overall coding style in that file:

Code is structured into cohesive blocks, which are prefixed by a comment which explains in english language the intention, pitfalls, limitations of the following code.

I find this quite elegant and readable. An ideal to aspire to.

I am not advocating nonsensical JavaDoc:

    // Get's foo from bar
    private Foo get_foo(Bar bar);
If you are able to just use names and types to document your intentions, pitfalls etc ... then by all means, do just this. E.g.

     for( person in address_book ) {
          body = template.render( name => person.name, ... )
          mail = Mail.new(person.email, body)

However, if stuff get's more nuanced don't be afraid to use english language to explain what you are doing. You future self will thank you : )
heinrichhartman 23 days ago [-]
> I would want that function to be multiple smaller functions with docstrings and such [...]

I have tried that style in the past, and have reverted to writing longer functions with intermittent comments. I now consider "single caller functions" a smell.

If logic is serial (do A, then B, then C) it's fine to have serial code:

   main() {
     ... A ...

     ... B ...

     ... C ...
The issue with splitting out the intermediate steps into functions is, that the serial flow is broken. Instead of the logic now looks something like

    A(...){ ... }
    C(...){ ... }
    main() { 
       ... B ...
Where B might have been a tiny task, that is not worth splitting out. In effect:

- The ordering of the logic is broken.

- Passing arguments can be a pain, if a lot of pieces are touched.

And what have you gained? Not sure there are many upsides besides debatable aesthetics of avoiding inline code comments.

zmmmmm 23 days ago [-]
> If you are able to just use names and types to document your intentions, pitfalls etc ... then by all means, do just this

That's sort of the point. Step 1, your code should be self explanatory. When the natural interpretation a reasonable person would have from reading the code differs from reality: that's when you add Step 2: add comments to "fix" the gap between perception and reality. The less Step 2 is necessary the better.

23 days ago [-]
Izkata 23 days ago [-]
An example straight from a new hire's code review a few weeks ago:

  // foo = 12345

  doThing1(12345, 5) // foo
  doThing2(12345, 8) // foo
Preferring self-descriptive code instead of comments helps stop them from doing things like this.
williamdclt 23 days ago [-]
> If you need to comment on what something is doing, usually you can move that behaviour into a function and test that function.

That's the usual argument, and the counter-argument is always the same: you shouldn't comment the what (though I'll argue there's always exceptions), you should comment the why.

Why are you doing this processing here rather than there? Why do you not apply the usual pattern in this specific case? Why does this code, that will make you want to refactor, has been written like this?

dodobirdlord 23 days ago [-]
> If you need to comment on what something is doing, usually you can move that behaviour into a function and test that function.

Strong disagree. As a general principle, a refactoring that changes no behavior should break no tests. It's all well and good to factor out a chunk of code into a separate internal function for code clarity, but don't go writing a test for it. Don't plumb your tests through the internals of the code. If you're factoring that piece of functionality out into the public interface of another component, sure, you should test the public interface of that component. But if you're factoring it out into an implementation detail of the same component it was originally part of don't write a test that cares about the details of you implementation. The functionality it provides should already be testable via calling the function it was originally factored out of.

anarazel 23 days ago [-]
> Comments: I find comments, outside of docstrings, a smell.

Neither function/type/whatever names, nor unit tests document architecture, concurrent behaviour, locking, ... to a significant degree. For simpler stuff that's fine, but it doesn't take that complicated a problem that some interdependencies aren't obvious anymore.

Even in the simpler cases that then often leads to APIs/Architecture that appears "fractured". Because the intent from the time the code was originally written isn't visible enough, subsequent work is designed differently, rebuilds parts of infrastructure, ... That leads to harder to maintain code over time.

IME there's a significant difference in how much effort is worthwhile to put into comments and understandable code depending on the expected lifetime, staff turnover, total size of a project.

keithnz 23 days ago [-]
the more testing the better? while having tests at unit and integration levels are good...

Test as little as possible/responsible.

I think it was Kent Beck who first articulated that, though it was something many people converged on in the early 2000s in the XP world. Of course it doesn't mean test nothing, it's recognizing tests are liabilities (as all code is) and we need to make sure they are serving a purpose otherwise delete them / refactor them to get rid of duplication of testing and overly verbose long winded tests that keep repeating things over and over again and again, saying the same thing repeatedly, doubling up on testing :)

galaxyLogic 23 days ago [-]
Wasn't it Kent Beck who came up with Extreme Programming and Test-Driven Development? I think testing was one of the big corner-stones of XP. At what point did that turn into "Test as little as possible"?

"Unit tests are one of the CORNER STONES of Extreme Programming (XP)"


Also see: https://hygger.io/blog/tests-in-extreme-programming/

If development is tests-driven and you should minimize the amount of tests then doesn't that also mean you should minimize the amount of development?

Well of course, do not develop more than is needed. But that kind of trivializes the whole agile ideology: "Develop As Little As Possible, that allows you to remain the most Agile"

Minimizing the amount of development also minimizes the number of bugs. Sounds like a great concept.

keithnz 23 days ago [-]
its the same concept as minimizing the amount of code through design and refactoring. Let the tests drive the code, refactor, and refactor / delte your tests when not needed anymore. :)

this is his SO answer where he talks about it... https://stackoverflow.com/questions/153234/how-deep-are-your...

galaxyLogic 22 days ago [-]
Makes sense. But it does seem like a shift in position from the very "test-centric" view of XP.

In the above link I don't see anything about "delete your tests when not needed anymore", or did I miss it?

How do you know when some tests are "not needed any more"? Isn't the idea of regression-testing to keep tests around so you know if any new code will break them? That should give you the "agility" to refactor your code, I think, is what the proponents of XP would say.

yodsanklai 23 days ago [-]
> Unit tests are for refactoring

I would say that unit tests impede refactoring. If your refactoring changes classes interfaces or API, you are likely to have to change your unit tests as well.

> Code that is easy to unit test tends to be more modular and have better architecture. If you are struggling to test a function

Same goes with documentation. If you can't explain simply what a function does, you may want to rewrite it.

honkycat 23 days ago [-]
> I would say that unit tests impede refactoring. If your refactoring changes classes interfaces or API, you are likely to have to change your unit tests as well.

Strongly disagree. How do you modify a function or interface if you do not know what breaks when you use that function?

Personally, I do not like to have to grok the entire codebase and keep a map of it in my brain at all times. I like to concentrate on the behaviour I am currently implementing and be VERY sure that the changes I am making are not breaking elsewhere.

If changing a function breaks a bunch of tests: Good. Otherwise, all of those broken tests would have been bugs I get to find in production and explain to my boss.

yodsanklai 23 days ago [-]
Suppose you have a service A, that uses two classes X and Y. Then you realize that it would be better for A to use X' and Y' (with different interfaces). If you have unit tests for X and Y, you will have to change these tests as well. If you do a lot of refactoring, you will spend a lot of time maintaining the unit tests. On the other hand, if you rely on integration tests (which test A), you still test X and Y, but your tests are less likely to change over time.

I'm not saying unit tests don't have their use, but as far as refactoring goes, I think they are a hindrance. Unless we talk about rewriting just a function.

neilkakkar 23 days ago [-]
Interesting. I love the idea of generating documentation from code - it does a lot of things right: Single source of truth (right now we have 3), easier to update when changing code as it's right there.

But I'm not sure everything fits in there. Where do you document processes like how to test stuff that isn't possible to test in a local-dev environment?

Or .. what the IDs that have some business meaning, mean.

honkycat 23 days ago [-]
> But I'm not sure everything fits in there. Where do you document processes like how to test stuff that isn't possible to test in a local-dev environment?

I feel like that would go into the README or an attached wiki page.

It is funny, after writing my MILLIONTH validation library, I've been thinking OpenAPI or APIBlueprint driving my validation and parsing library at my web application boundaries is the way to go... which is kind of the opposite. Documentation driving my software xD

Ididntdothis 23 days ago [-]
I think this is pretty good.

As a pretty senior dev myself I always tell people to have an actual design in mind. Know what you are trying to achieve and when something goes wrong you should be able to explain what you expected the system to do on that situation . A lot of people don’t seem to have a clear mental image of the end goal but are overwhelmed .

Of course you should be flexible but you need to know where you want to be in order to make good decisions.

ulkesh 23 days ago [-]
I like the article. I just wish the senior software engineer also included teaching humility. The article isn't written with any ego, so I commend the author, but it would be ideal for any mentor to also teach what to do when being wrong, making a mistake, costing the company money, etc.
contingencies 23 days ago [-]
The main value in software is not the code produced, but the knowledge accumulated by the people who produced it

Don't agree with this at all. If you're relying on people to maintain knowledge then you're doing it wrong and setting yourself up for failure. Document the why.

tehlike 23 days ago [-]
You are thinking just the running system. The decisions behind why, the quirks of the software, how that all fits together, and the knowledge of why you should do certain things (like monitoring, experiments and whatnot) is important.

Good luck documenting all that. Good luck making that document discoverable and readable.

seren 23 days ago [-]
Often you can deduce the "why" from the code because it makes some sense, but you can almost never find out is the "why not" .

Have they tried something else ? Was it the best solution chosen after a review or something quickly put together ? Likely you'll never know.

atoav 23 days ago [-]
accumulated doesn’t allow any qualitative judgement about the way they treat that knowledge. So we shouldn’t assume the worst.

I suggest the opposite: if they take their own words seriously and this knowledge is the main value than I’d assume they grow in great lenghts documenting that main value — because it would be (as you rightly noticed) lost.

BurningFrog 23 days ago [-]
The way I think of it, the knowledge should be in the code. Including the tests.

To me that is one of the major goals of any code writing. Some new hire I've never met should have a fair chance of working with this in 6 months.

icebraining 23 days ago [-]
There was an article from 1985 by Peter Naur on this posted recently on HN:

"Programming as Theory Building":



X-Cubed 23 days ago [-]
My take on this point (and something I agree with) is that you shouldn't get too attached to a particular implementation. It can be useful to build a prototype and throw it away, then use that knowledge to build a better version, than to try to keep building on top of the prototype.

There's nothing in their point that refers to documentation.

lonelappde 23 days ago [-]
Parent didn't say what you claim to disagree with. The documentation is how the knowledge is accumulated. People maintain documentation.
contingencies 23 days ago [-]
the code produced

I would argue that to any experienced software person, in the context of a project the code means "code and documentation" (containing domain knowledge, implementation history and intent inexorably bound together as one unit). Whereas, the quoted phrase suggests a dichotomous perception.

ztjio 23 days ago [-]
Makes me a little ill that the author thinks Jeff Atwood coined that old-ass joke.
neilkakkar 23 days ago [-]
.. Nopes, but it was the quickest reference I could find for the joke. I don't like to put quotes in without the source.
LeonB 23 days ago [-]
Hi Neil. The attribution is correctly given here: https://martinfowler.com/bliki/TwoHardThings.html

(Hint... it's me.)

neilkakkar 23 days ago [-]
Hey Leon, thanks!

I've updated the website :)

asgeir 23 days ago [-]
Cunningham's law in action.

"The best way to get the right answer on the Internet is not to ask a question, it's to post the wrong answer."


LeonB 21 days ago [-]
You know it wasn’t Cunningham who said that? (Just kidding)
kinkrtyavimoodh 23 days ago [-]
Wrong information is worse than no information. If the source is not known or if you don't want to spend the time to find it, just say "unknown" or "as someone said"
ggambetta 23 days ago [-]
IMO, an unattributed quote (or attributed to "unknown", or you know, doing slightly more research than "the quickest reference you can find") is better than putting a known-wrong reference.
chaboud 23 days ago [-]
“De-risking is the art of reducing risk with the code that you deploy.

What all steps can you take to reduce the risk of disaster?”

Honestly, I talk about derisking most in two contexts in our projects: schedule, invention.

Normally this means that derisking is about frontloading unknowns and finding pivot decisions that reduce the likelihood of getting too far in the wrong direction or accumulating too much uncertainty.

I don’t use “risk” too often when talking about fault tolerant code or system design. If you’re taking on “risk” in code, like the chance of a lost message, a race condition, or corrupted data, I’m going to take away the keys.

Note: I encounter shoddy “we can go hours without a crash, so it’s good” work more than I’d like to admit. It is possible to know why code and systems fail (and account for it) much more than has become industry norm these days.

NotUsingLinux 23 days ago [-]
The article as the comments here read very strange. Like a place where there is no place for people. There can be space (real physical as well as a culture) for people, lets give team human a try. Please let's not be working drones that optimize towards questionable goals...


7532yahoogmail 23 days ago [-]
This article is fluff. Presented with a gosh-this-is-cool-isnt-it narrative, nothing here suggests senior engineer. Senior engineers must have a much more nuanced assessment about the interaction between organizational norms, teamwork, and software. There's no penetrating insights here. Software is semi-formal at best and more a hidden Markov chain at best. Indeed the central questions to software engineering are deferred as questions.
xuesj 23 days ago [-]
Good programmer should be good at writing essay.
greyskull 23 days ago [-]
> In the end, we went with a database with role access control (only our machines and us can talk to the database). Our code gets the secrets from this database on startup.

How does the code get access to the database?

I've lived in AWS-land for so long, I don't know how the non-cloud world manages secrets.

sidcool 23 days ago [-]
There are other blogs by Neil Kakkar that I really enjoyed, including the one on Human log. It's quite nice and practical. https://neilkakkar.com/the-human-log.html
greyhair 23 days ago [-]
Requirements matter. Design matters. Data matters. Documentation matters. Source control matters. Defect tracking matters.

All source code eventually "wears out" and has to be rewritten.

mleonhard 22 days ago [-]
> I’ve come to love testing so much that I feel uncomfortable writing code in a codebase without tests.

This person became a good engineer in only one year! :)

aleksgrach 23 days ago [-]
Я бы с радостью пообъщялся с инженером-програмиста.
greenie_beans 22 days ago [-]
my mentor writes bad code
greenie_beans 14 days ago [-]
want to report back that i can't write good code either!
neilkakkar 23 days ago [-]
einpoklum 23 days ago [-]
> Things I Learnt from a Senior Software Engineer

I guess spelling wasn't one of them?

But other than that, it's a nice blog post. I like the "human log" suggestion - should really pick that one up. I've been doing that already, but only for my servers...

whitepoplar 23 days ago [-]
What's wrong with the spelling? He's from the UK.
OJFord 23 days ago [-]
I don't know what GP has a problem with, but I don't think the author's British - 'internalize' in the opening paragraph.
23 days ago [-]
Izkata 23 days ago [-]
Probably "learnt" vs "learned".
stan_rogers 23 days ago [-]
The zed disease has, unfortunately, spread.
galaxyLogic 23 days ago [-]
> I like the "human log" suggestion

What I do is I commit to Git every day and I enter a commit-comment

adamnemecek 23 days ago [-]
These posts keep repeating the same things.

"There are two hard things in computer science: cache invalidation, naming things, and off-by-one errors. - Jeff Atwood"

This is not novel, nor insightful.

"Premature Optimization Is the Root of All Evil". I've reached a point where every time I hear someone say this, I legitimately ignore everything else they say.

lazzlazzlazz 23 days ago [-]
You've become that unhelpful curmudgeon you used to dismiss.
LeonB 23 days ago [-]
It's also most definitely not a Jeff Atwood joke.
sergiotapia 23 days ago [-]
We all "zed shaw" every once in a while