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

261–270 of 301 posts

Re: Things I Learnt from a Senior Software Engineer

#261

Post by gumoro »

askafriend wrote: post #58
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.)

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

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

Re: Things I Learnt from a Senior Software Engineer

#262

Post by inflatableDodo »

Scarblac wrote: post #180
harrisonjackson wrote: post #118

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…

So in all three cases, your focus is gone and what you were doing has stopped.

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.

Re: Things I Learnt from a Senior Software Engineer

#263

Post by tc7 »

nitrogen wrote: post #140
rbavocadotree wrote: post #97

Earlier quoted context omitted.

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.

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.

Really seems like I should be better at golf, then. :tear

Re: Things I Learnt from a Senior Software Engineer

#264

Post by crucialfelix »

mikekchar wrote: post #122
Everlag wrote: 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,…

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.

Re: Things I Learnt from a Senior Software Engineer

#265

Post by chasd00 »

aspaceman wrote: post #193
Scarblac wrote: post #180

Earlier quoted context omitted.

So in all three cases, your focus is gone and what you were doing has stopped.

Helping a junior and maintaining relationships with your fellow seniors is a part of the job too.

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.

Re: Things I Learnt from a Senior Software Engineer

#266

Post by teddyh »

username90 wrote: post #219
teddyh wrote: post #191

Earlier quoted context omitted.

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

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

Re: Things I Learnt from a Senior Software Engineer

#267

Post by yodsanklai »

honkycat wrote: post #249
yodsanklai wrote: post #229

Earlier quoted context omitted.

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

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.

Re: Things I Learnt from a Senior Software Engineer

#268

Post by mindcrime »

landhar wrote: post #90
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?

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

In a similar vein, the acronym for Web Ontology Language is OWL[1].

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

Re: Things I Learnt from a Senior Software Engineer

#269

Post by maccard »

jedberg wrote: post #167
pmiller2 wrote: post #91

Earlier quoted context omitted.

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

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.

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.

Re: Things I Learnt from a Senior Software Engineer

#270

Post by mindcrime »

jmpeax wrote: post #200
jchook wrote: post #61

Earlier quoted context omitted.

As long as you don't go into potentially offensive humor

Isn't there like a law or razor or something named after someone that says all humor will one day be offensive?

If not, there probably should be.

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

Post reply on HN