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

41–50 of 301 posts

Re: Things I Learnt from a Senior Software Engineer

#41

Post by atoav »

amzans wrote: post #3

> Good engineers themselves design systems that are more robust and easier to understand by others. This has a multiplier effect, letting their colleagues build upon their work much more quickly and reliably - How to Build Good Software The advice above is probably one of the things which would have the most impact across all your activities as a developer. When people talk about simplicity in software, they don’t ne…

This is also good advice for other areas, even if you are 100% sure you are the only person to ever lay their eyeballs on what happens behind the curtain.

I worked in VFX and film post production and this spirit usually saves yourself a lot of hassle in day to day actions and even more so if you get ill, can’t do the job anymore or decide to split it up.

The way I worked in VFX certainly had a big impact on my programming. Some work ethics just make sense.

Re: Things I Learnt from a Senior Software Engineer

#42

Post by [deleted] »

honkycat wrote: post #29
heinrichhartman wrote: post #24

Earlier quoted context omitted.

I have heard this so many times: > Comments: I find comments, outside of docstrings, a smell. But is this really the case? I find comments like these invaluable: /* * Mark walreceiver as running in shared memory. * * Do this as early as possible, so that if we fail later on, we'll set * state to STOPPED. If we die before this, the startup process will keep * waiting for us to start up, until it times out. */ SpinLock…

This is EXACTLY where comments should be used, great example! Extremely high-performance database code is not what most of us are doing, however. We are doing enterprise software development to send emails and scrape money out of people. I would want that function to be multiple smaller functions with docstrings and such, but obviously, that would add stackframes to the call stack and be slower. Additionally, many mo…

[deleted]

Re: Things I Learnt from a Senior Software Engineer

#43

Post by BurningFrog »

contingencies wrote: post #37

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.

The way I think of it, the knowledge should be in the code. Including the tests.

To me that is one of the major goals of any code writing. Some new hire I've never met should have a fair chance of working with this in 6 months.

Re: Things I Learnt from a Senior Software Engineer

#44

Post by anarazel »

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…

> Comments: I find comments, outside of docstrings, a smell.

Neither function/type/whatever names, nor unit tests document architecture, concurrent behaviour, locking, ... to a significant degree. For simpler stuff that's fine, but it doesn't take that complicated a problem that some interdependencies aren't obvious anymore.

Even in the simpler cases that then often leads to APIs/Architecture that appears "fractured". Because the intent from the time the code was originally written isn't visible enough, subsequent work is designed differently, rebuilds parts of infrastructure, ... That leads to harder to maintain code over time.

IME there's a significant difference in how much effort is worthwhile to put into comments and understandable code depending on the expected lifetime, staff turnover, total size of a project.

Re: Things I Learnt from a Senior Software Engineer

#45

Post by grogenaut »

neilkakkar wrote: post #26
grogenaut wrote: post #23

Earlier quoted context omitted.

I find that team names change more frequently than responsibility in a large org. Also using a team name makes people assume ownership of decisions with that team. That's why I prefer service name. However I haven't thought much about shared use clusters.

We've had the same name for the past 7 years, so going by the future estimates with no extra useful information, I expect us to have the same team name for 7 more years :P

Makes things easy for you then. My company, every manager hire decides to change team names. Had a vp who used to be marketing that changed the org name like 4 times in 2 years. Cause name changes fix everything. Essentially we have a few teams / orgs with name of the week.

Re: Things I Learnt from a Senior Software Engineer

#46

Post by LeonB »

neilkakkar wrote: post #11
ztjio wrote: post #9

Makes me a little ill that the author thinks Jeff Atwood coined that old-ass joke.

.. Nopes, but it was the quickest reference I could find for the joke. I don't like to put quotes in without the source.

Hi Neil. The attribution is correctly given here: https://martinfowler.com/bliki/TwoHardThings.html

(Hint... it's me.)

Re: Things I Learnt from a Senior Software Engineer

#47

Post by LeonB »

adamnemecek wrote: post #14

These posts keep repeating the same things. "There are two hard things in computer science: cache invalidation, naming things, and off-by-one errors. - Jeff Atwood" This is not novel, nor insightful. "Premature Optimization Is the Root of All Evil". I've reached a point where every time I hear someone say this, I legitimately ignore everything else they say.

It's also most definitely not a Jeff Atwood joke.

Re: Things I Learnt from a Senior Software Engineer

#49

Post by sk5t »

stefs wrote: post #30
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…

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.

Nice! Could take a turn for the worse when you need something smaller than E. coli though--you'll be wishing you named the Chromecast "tardigrade" when some lightswitch has to be named "herpes."

Re: Things I Learnt from a Senior Software Engineer

#50

Post by cwbrandsma »

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 needed to wrap the code that handled thread management that I use in Swift. I called the component Threader, and in the comments I mention I named it after the TMNT character Shredder.

Two things came from that: I have gotten a chuckle from all the developers I introduced to that code, and no one has forgotten about it.

Some humor is useful.

Post reply on HN