Earlier quoted context omitted.
It's sad to see in the current century that a group of erstwhile professionals jump to "porn stars".
Why is this being downvoted? It is highly inappropriate to do this in a work context.
Things I Learnt from a Senior Software Engineer
151–160 of 301 posts
Re: Things I Learnt from a Senior Software Engineer
#152Earlier quoted context omitted.
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
#153> 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…
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…
Re: Things I Learnt from a Senior Software Engineer
#154Earlier quoted context omitted.
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…
I improved exponentially my concentration and quality of work while he showed up that previously he was spending large amount of time watching YouTube/news websites/shows instead of doing work and he is frustrated that he has to do real work now.
Re: Things I Learnt from a Senior Software Engineer
#155Earlier quoted context omitted.
At the last place I worked at (a smaller ISP) we were a little spastic with our naming schemes. Sometimes boring -- web-1, web-2, web-3, web-4, ... and sometimes more entertaining -- we named a cluster of content filtering servers after porn stars (sindee, etc). Now everything is a VM so I'm back to naming "servers" by their function because I don't really need to worry about them being multifunction or evolving.
It's sad to see in the current century that a group of erstwhile professionals jump to "porn stars".
You realise someone has to do this stuff, right?
Re: Things I Learnt from a Senior Software Engineer
#156Just 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…
Strong disagree. As a general principle, a refactoring that changes no behavior should break no tests. It's all well and good to factor out a chunk of code into a separate internal function for code clarity, but don't go writing a test for it. Don't plumb your tests through the internals of the code. If you're factoring that piece of functionality out into the public interface of another component, sure, you should test the public interface of that component. But if you're factoring it out into an implementation detail of the same component it was originally part of don't write a test that cares about the details of you implementation. The functionality it provides should already be testable via calling the function it was originally factored out of.
Re: Things I Learnt from a Senior Software Engineer
#157> 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".
Re: Things I Learnt from a Senior Software Engineer
#158The 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.
Write down everything you do and honor it as an accomplishment.
Getting out of bed. Reading an article about your craft. Brushing your teeth. Showering. Dressing. Reading somebody else's PR. Commenting on somebody else's PR.
Every. Single. Thing.
Attending a meeting. Having a hallway conversation. Answering an email or ten.
Not taking your own life. Surviving. Not doing other self-destructive things.
Chances are, if you are able to get out of bed (not always a given) you probably did a lot of "little" things. Those are achievements. And in your depression those things may have taken more effort than running a 5-minute mile.
Sure, the goal is to eventually accomplish more. That's fine. But honor the things you're doing.
And hey... good luck.
Re: Things I Learnt from a Senior Software Engineer
#159> 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.
Re: Things I Learnt from a Senior Software Engineer
#160Earlier quoted context omitted.
I enjoy seeing a bit like of humor in the code, especially silly-but-clear comments and names less important parts of code. For a one shot task, why name it ScheduledObjectStorageDownloader when you can name it AutoCloudStorageFileYoinker?!
While I'm not 100% against humor in a codebase, ever since my company started hiring more engineers internationally, I've become more tuned in to whether a name that uses slang like "yoinker" will be understood by someone who doesn't know English as a first language.