Live data from Hacker News

Things I Learnt from a Senior Software Engineer

neilkakkar.com

211–220 of 301 posts

Re: Things I Learnt from a Senior Software Engineer

#211
post #81

> 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 sto…

So how do you handle pair programming? It’s almost the same thing to me.

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.

Re: Things I Learnt from a Senior Software Engineer

#212

Earlier quoted context omitted.

Compromise?

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 int…

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.

Re: Things I Learnt from a Senior Software Engineer

#213
post #30
post #21

> 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 nu…

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.

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.

Re: Things I Learnt from a Senior Software Engineer

#214

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.

There was an article from 1985 by Peter Naur on this posted recently on HN:

"Programming as Theory Building":

https://web.archive.org/web/20150224214427/http://www.dc.uba...

https://news.ycombinator.com/item?id=20736145

Re: Things I Learnt from a Senior Software Engineer

#215

Earlier quoted context omitted.

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 anythi…

The only time I (a PM) would do this is when you are working on validation messages / error messages / user facing text.

How would you know this without entering their personal space?

Re: Things I Learnt from a Senior Software Engineer

#216
post #104

Earlier quoted context omitted.

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.

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.

prodsys3 pales in comparison to when I had to decommission gandalf and galadriel.

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

Re: Things I Learnt from a Senior Software Engineer

#217
post #151

Earlier quoted context omitted.

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.

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 th…

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.

Re: Things I Learnt from a Senior Software Engineer

#218
post #164

Earlier quoted context omitted.

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.

> 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”.

I'm naming my server Godwin.

Re: Things I Learnt from a Senior Software Engineer

#219
post #191

Earlier quoted context omitted.

> 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…

> 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.

Branch prediction is a very good optimization though, you'd lose quite a lot if you forbade people from using it.

Re: Things I Learnt from a Senior Software Engineer

#220

Earlier quoted context omitted.

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…

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.

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.
Post reply on HN