Live data from Hacker News

Things I Learnt from a Senior Software Engineer

neilkakkar.com

81–90 of 301 posts

Re: Things I Learnt from a Senior Software Engineer

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

Re: Things I Learnt from a Senior Software Engineer

#82

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

What's wrong with the spelling? He's from the UK.

I don't know what GP has a problem with, but I don't think the author's British - 'internalize' in the opening paragraph.

Re: Things I Learnt from a Senior Software Engineer

#83
post #60

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…

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

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

http://www.extremeprogramming.org/rules/unittests.html

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.

Re: Things I Learnt from a Senior Software Engineer

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

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.

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.

Re: Things I Learnt from a Senior Software Engineer

#85

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

> I like the "human log" suggestion

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

Re: Things I Learnt from a Senior Software Engineer

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

Isn't Cloud-Computing something that should make it unnecessary to name individual computers?

Re: Things I Learnt from a Senior Software Engineer

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

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.

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.

Re: Things I Learnt from a Senior Software Engineer

#88

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.

Parent didn't say what you claim to disagree with. The documentation is how the knowledge is accumulated. People maintain documentation.

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.

Re: Things I Learnt from a Senior Software Engineer

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

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.

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.

Re: Things I Learnt from a Senior Software Engineer

#90

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

Not sure if there’s a name for this, but my favourite example is settling on UTC as the acronym for Coordinated Universal Time:

https://en.m.wikipedia.org/wiki/Coordinated_Universal_Time#E...

Post reply on HN