Advice on Noetic Nought

Self-care tips for new developers

Wed, 24 Oct 2018 20:14:00 +0530

A couple of weeks ago, I was at PyCon India – the 10th edition, the 8th PyCon I was attending. It was great to see so many enthusiastic young developers, attending their first PyCon. With each year, as the event gets bigger, you see more and more of them. Lot of curiosity, and enthusiasm to become better programmers.

The conference had a whole bunch of talks, catering to people with varied interests, at different stages in their career – war stories, tips and tricks, helpful advice on getting started with a library or tool, thoughts on the community culture, etc. With each passing year, there are more and more proposals for talks, and a lot of good talks have to be left out due to constraints on the number of talks that the conference can accommodate.

Having said that, I’d have liked to see a talk on self-care tips for developers – advice on staying sane and productive in the long run. It is quite common for programmers to get burnt-out. I’m sure there are some useful lessons to be shared by everyone who has been programming professionally for a while – ranging from about a couple of years to many decades!

In a hallway conversation, Noufal was telling some of us about the Okinawa martial art lessons he’s been taking - it was inspiring to see how seriously he takes the lessons. A lot of programmers that I know, who have been programming for a while, have other interests that they pursue quite seriously, to take time off from programming. It would be nice to have someone speak about mental health and self care in a talk, rather than hope that people pick it up in hallway conversations. Explicit is better than implicit.

I was considering doing a lightning talk on this, but I didn’t get in touch with the organizers early enough to get a slot. So, here’s a blog post.

Disclaimer: Not all of these are things I’m good at doing consistently, but they are things that have at some point helped me. This post is also a way for me to write down things that I (or others) can come back to whenever necessary.

Take breaks

We are often so engrossed in getting something to work, that we lose track of time – slumping in our chairs for hours on end, forgetting to eat, hydrate or move around.

Our bodies weren’t made for this – we were built to move around. Also, stepping away from the problem for a bit, after wrestling with it for a while, brings a fresh perspective and new ideas.

You could use a tool like workrave to remind you to take regular breaks and stretch. Or use a Pomodoro timer. Another trick is to drink keep drinking water regularly, so you are forced to get up and take a piss, every once in a while.

Hydrate, Eat and Sleep

Being dehydrated can make one feel tired and sleepy, making it hard to focus well. Same goes for being hungry and sleep-deprived. Not having enough glucose in your blood has been shown to cause people to make bad decisions.

Mental work uses up a lot of energy, even if we seem to be just sitting around all day, and not expending much more energy than sleeping. It is important to feel good physically to work effectively.

You could have a bottle of water next to you, that you frequently drink from and keep re-filling at breaks. Don’t skip on your lunch to use that extra half an hour being productive. Keeping some snack accessible for you to eat towards the end of the day, when you are tired, helps. Use a sleep tracker or just roughly track sleep each night manually. Make sure you are getting enough of it.

Invest in a good set-up

We spend around half of our waking time at work - over a life time, that’s a lot of time! Sitting in a bad posture, or doing a only-slightly-uncomfortable action over and over, can easily grow into bigger problems in the long run.

You deserve good quality equipment, that “fits” you well. Get yourself a good keyboard and mouse, an external monitor, or whatever it is that you think will make your body thank you. If you end-up working a lot from your home office, invest in a good chair and a table.

Sunlight & Exercise

Being locked up in our office buildings all day doesn’t help with how much exposure we get to the sun. Not getting enough sunlight regularly can effect us both mentally and physically. Same goes for exercise. Getting some exercise everyday has been shown to have significant mental and physical health benefits.

You can start playing a sport, if hitting the gym or doing something alone seems like a chore. Playing a team sport helps even more since there are other people you are accountable to. Try to get some sunlight every morning, even if it is just standing out in the sun, while you drink your coffee.

Take Vacations

Switch off completely, and give your body and mind the rest they deserve. The break not only lets you rejuvenate physically, but also gives your brain the time to synthesize all the inputs it has, and come back with surprising ideas or solutions to problems that have been troubling you for a while.

The importance of taking a break is often forgotten, when we have so much to do. Honestly, I’m not very good at taking regular vacations, myself.

But, having a fixed time every year to take a vacation is something that I’ve seen working. For example, 2 weeks around your birthday every year, you can decide to take a vacation.

Do other things

We get into the game because we are really excited by the things we can build by flipping bits. We get so obsessed with it, that we lose ourselves in it, oblivious to the world outside. All the people we hangout with are people very similar to us.

Often, we are building stuff for people very unlike us. It’s very helpful to see the world from a different perspective than ours. Also, there is only so much we can express through code. There is a whole lot of us that can be expressed in other ways.

Pick up a team sport, do improv/stand-up, draw or paint, write, learn a martial art, join a cross fit gym – anything that you find interesting, other than writing code. Hangout with people who do very different things everyday than what you do. Their completely different perspective at life will make you a better programmer and a better person.

Avoid distractions

The internet can be so distracting! But, as developers, we tend to be constantly connected, leaving ourselves vulnerable to all this distraction. All these distractions can lead to very expensive context switches.

I’ve found getting into, and working in flow-states to be enormously satisfying. What I’m actually working on, doesn’t matter very much when I’m to deeply focus on something I want to be doing.

Creating an environment for yourself, where its easy to get into these states, is totally worth it. I’ve found using Pomodoros to be quite helpful, when I’m feeling distracted. Shutting off the Internet, or using a tool like get-shit-done helps with stopping myself from getting distracted by cat videos on the internet. Turning off all notifications on my phone and computer is another thing that is quite effective I also find it helpful to not be able to constantly have sight of the clock on my computer - so I work with all my windows full-screen. Leaving the phone in another room or in my bag works great, too. You can find a lot more tips on the internet, if these tricks aren’t up your alley.

If you see your team over-working themselves, and holding exhaustion as a badge of honour, please be the person to strike conversations around self care. Your team will thank you.

I’ve only listed down some of the things that I’ve found helpful. But, I hope this serves as a good starting point. Also, do take a look at selfcare.tech for more resources and advice.

Thanks Akilesh Mani and Shantanu Choudhary for reading drafts of this and giving helpful suggestions.

PyCon India 2016 - Propose a talk

Tue, 31 May 2016 00:00:00 +0530

CFP for PyCon 2016 is open and you should propose a talk!

There has been a lot of discussion on trying to improve the talk quality at the events. As my bit of contribution to this, below is a re-hash of some good advice from the internet on why you should give a talk, and how to submit a good proposal.

Why?

You needn’t be an expert on a topic. If you have enough experience about something to help make the next person’s experience with it better, you are good.
Its a great way to find people who are interested in the same things as you are and to get to talk to them. If you are an introvert, you should definitely be speaking!
Proposing and giving a talk is about thinking about something hard enough to refine your thoughts, and being able to explain it to others. Its a useful skill to hone.

How?

Talks are entertainment. Pick a topic that you are excited about and fascinated by. Let it be a general topic that will have a significant number of people interested in it.
What you want the attendees to be telling their friends about your talk, after they go back. Make it the objective of your talk.
Submit a complete, clear and compelling proposal. Show the reviewers that you are willing to put in the effort to prepare for and to give a great talk. Here are a bunch of proposals to see and learn from.
Submit an outline along with your talk. Show the talk can be delivered in the given time and will be interesting. Include an indication of how much time you intend to spend on each part of your talk.
Choose a good title. The title is what catches the attention of your audience when they are trying to pick a talk. Avoid buzz words.
Get feedback. Like any writing, feedback can be helpful at all stages – brainstorm while choosing topics to getting critique on the full abstract.
Convince the reviewers that you can give a well-rehearsed and entertaining – link to previous talks you’ve given, include links to any testimonials you’ve received from your audience, etc. If you don’t have a previously recorded talk, give a small talk to your friends or colleagues and have it recorded.

References

PyCon US has some good advice on how to submit a proposal and most of it is generic enough for you to use for PyCon India, or any other conference.
These posts (1 2 and more) by Jesse Davis are so so good!
I also liked “The Talk on Talks” by Zach Holman.

Martin Fowler on Refactoring @ RubyRogues

Sat, 25 Oct 2014 00:00:00 +0530

I stumbled on a Ruby Rogues podcast yesterday, which had Martin Fowler as the guest. I really enjoyed the discussion on Refactoring (the noun, the verb and the book!)

Martin clarified in the podcast that refactoring (the verb/process) is a sequence of very small refactorings, while you keep making sure that you can run the test suite always. A refactoring (noun) is a change where you change the structure of the code without any externally observable changes, with the intent of making it easier to understand and cheaper to change in future.

I also really liked the metaphor of a ‘healthy code base’. Refactoring is, then, the process of keeping healthy – exercise, speaking metaphorically. You can stack up all the exercise you need to do, until you get really unfit. Refactoring, similarly, needs to be done regularly, to keep the code base healthy. This lets you go faster, in the future.

I also really liked the advise about trying to push back the mental contexts you build, while trying to debug/understand some code that is not very clear, by refactoring the code to make it clearer. Code needn’t be one big chunk of cryptographic text. Code is writing. It should be clear and understandable. Or, at least we should strive to make it so!

The discussion, as always on this podcast, was very lively, pleasant and enjoyable! Enjoy!

Best Practices for Scientific Computing

Mon, 24 Dec 2012 00:00:00 +0530

Shantanu and I gave a short talk titled “Software Carpentry for Scientists” for the graduate students of Chemical Engineering department, IISc, this Friday. We gave a short introduction to Git, TDD, Numpy/Scipy, etc and mentioned a few things from Greg Wilson et al’s paper.

I promised to revert to them with links to a few resources. I figured it would be more beneficial, if I just put it in a publicly available place.

A summary of the paper by Greg Wilson et. al., is below.

Useful resources

Software Carpentry

Paper by Greg Wilson et. al.
Software Carpentry

Git & version control

TDD

SciPy

http://scipy-lectures.github.com

Python

http://docs.python.org/tutorial

GUI tools in Python

Summary of paper by Greg Wilson et. al.

Write programs for people, not computers
- a program should not require its readers to hold more than a handful of facts in memory at once.
- names should be consistent, distinctive and meaningful.
- code style and formatting should be consistent.
- all aspects of software development should be broken down into tasks roughly an hour long
Automate repetitive tasks
- rely on the computer to repeat tasks
- save recent commands in a file for re-use
- use a build to automate scientific work-flows
Use the computer to record history
- software tools should be used to track computational work automatically.
Make incremental changes
- work in small steps with frequent feedback and course correction
Use version control
- use a version control system
- everything that has been created manually should be put in version control
Don’t repeat yourself (or others)
- every piece of data must have a single authoritative representation in the system
- code should be modularized rather than copied and pasted
- re-use code instead of rewriting it
Plan for mistakes
- add assertions to programs to check their operation
- use an off-the-shelf unit testing library
- use all available oracles when testing programs
- turn bugs into test cases
- use a symbolic debugger
Optimize software only after it works correctly
- use a profiler to identify bottlenecks
- write code in the highest-level language possible
Document design and purpose, not mechanics
- document interfaces and reasons, not implementations
- refactor code instead of explaining how it works
- embed the documentation for a piece of software in that software
Collaborate
- use pre-merge code reviews
- use pair programming when bringing someone new up to speed and when tackling particularly tricky problems
- use an issue tracking tool

Advice - Programming in Elisp

Fri, 06 Aug 2010 00:00:00 +0530

Below is a mail sent by Eric Schulte to the org-mode mailing list answering a query on how to write elisp for org-mode. I am reproducing it here, since it is useful advice for me. The actual thread is here.

The way that I learned how to program in emacs lisp was mainly using two commands `elisp-index-search’ bound to `C-h e’ on my system, and most importantly `describe-function’ bound to `C-h f’. With `describe-function’ you can look at the source code of functions whose behavior you are familiar with, you can then copy portions of the code to your scratch buffer where they can be edited and evaluated with `eval-defun’ bound to `C-M-x’. Now with Babel, instead of doing this in the scratch buffer you could do this in emacs-lisp code blocks in an org file, enabling notes and hierarchical organization – it can be nice to have your noodling all collected in one file for later reference.

If you are going to do any serious work with lisp, I would emphatically recommend using paredit-mode, and becoming friends with the Sexp movement functions

C-M-f runs the command paredit-forward C-M-b runs the command paredit-backward C-M-u runs the command backward-up-list C-M-k runs the command kill-sexp C-y runs the command yank

They allow you to manipulate lisp code on the level of logical expressions, the utility of which can not be over stated.

As for working with Org-mode in particular, I’d recommend looking at the documentation and source-code of Org-mode functions with `describe-function’, and then looking for how these functions are actually used in the Org-mode code base with `rgrep'.

For a more structured learning experience, I’ve heard very good things about http://www.gnu.org/software/emacs/emacs-lisp-intro/, although I haven’t used it myself.

Hope this helps. Happy Hacking – Eric