Live data from Hacker News

Things I Learnt from a Senior Software Engineer

neilkakkar.com

141–150 of 301 posts

Re: Things I Learnt from a Senior Software Engineer

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

Re: Things I Learnt from a Senior Software Engineer

#142
post #4

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

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

This is really interesting. I’m going to try it.

Re: Things I Learnt from a Senior Software Engineer

#143

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

Re: Things I Learnt from a Senior Software Engineer

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

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.

Re: Things I Learnt from a Senior Software Engineer

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

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.

Re: Things I Learnt from a Senior Software Engineer

#146

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

Re: Things I Learnt from a Senior Software Engineer

#147

Earlier quoted context omitted.

How do you make a service call or ssh into a machine without a name?

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

Why is this downvoted?

Re: Things I Learnt from a Senior Software Engineer

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

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.

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)

Re: Things I Learnt from a Senior Software Engineer

#149
post #146

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

Exactly, the following is fine:

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

The GodComponent as a name is not.

Re: Things I Learnt from a Senior Software Engineer

#150
“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.

Post reply on HN