Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Things I Learnt from a Senior Software Engineer

neilkakkar.com

Post reply on HN
Print view View original

241–250 of 301 posts

Re: Things I Learnt from a Senior Software Engineer

#241

Post by OJFord »

sharadov wrote: post #239
OJFord wrote: 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…

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.

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.

Re: Things I Learnt from a Senior Software Engineer

#242

Post by rmetzler »

dotancohen wrote: post #184
afarrell wrote: post #169

Earlier quoted context omitted.

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.

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.

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.

Re: Things I Learnt from a Senior Software Engineer

#243

Post by jolmg »

cortesoft wrote: post #139
tolien wrote: post #63

Earlier quoted context omitted.

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

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.

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.

Re: Things I Learnt from a Senior Software Engineer

#244

Post by mixmastamyk »

HiFaraz wrote: post #161
phnofive wrote: post #64

Earlier quoted context omitted.

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?

I'd call that a compromise.

I like the sound of "anti-compromise."

Re: Things I Learnt from a Senior Software Engineer

#245

Post by wool_gather »

dotancohen wrote: post #186
teddyh wrote: 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…

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

Certainly:

- Dr. Sofia Cerny, the brilliant Czech topologist

- Vlad, a fifth-generation Ukrainian dairy farmer

and

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

Re: Things I Learnt from a Senior Software Engineer

#246

Post by dgritsko »

philwelch wrote: post #54
caymanjim wrote: post #48

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

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

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.

Re: Things I Learnt from a Senior Software Engineer

#247

Post by kemiller2002 »

OJFord wrote: 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…

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.

Re: Things I Learnt from a Senior Software Engineer

#248

Post by Spoom »

sergiosgc wrote: post #216
taneq wrote: post #104

Earlier quoted context omitted.

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.

At least the memes write themselves.

Re: Things I Learnt from a Senior Software Engineer

#249

Post by honkycat »

yodsanklai wrote: post #229
honkycat wrote: post #12

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

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

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

Re: Things I Learnt from a Senior Software Engineer

#250

Post by cr0sh »

greyhair wrote: post #222
ken wrote: post #99

Earlier quoted context omitted.

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.

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.

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

Post reply on HN