How to decide upon future weekly questions?

First and foremost, keep clients and work colleagues (especially management people) out of your personal life as much as possible.

Communicate to the rest of the team and clients (if in a client facing role) when you will and won't be available. Also communicate your concerns about any unrealistic deadlines.

Most of the times, this is bound to be ineffective. So, keep phone on silent (or flight mode) at night and during weekends. Also don't call back in case there is a missed call from anybody from work colleagues.

I deviate from this only if there is a go live or similar activity going on.

Even these guys are jumping on the migrate from GitHub train...

Git, Mercurial and others are distributed version control systems. Maybe it would have a federated version control system for hosting open source software...

Mainly listening to music. Sometimes taking a break or a good night's sleep also helps.

A small program I wrote in Turbo C which attempted to mimic the Starfield screensaver. This was the first moderately complex program that I wrote which drew something on the screen through code.

Something I refer to as the "Lost Cause Syndrome".

Basically you start working on a project enthusiastically with the resolution to write the best possible code. But either one (or some or all) of management, client and colleagues succeed in transforming the project into a comedy (or tragedy, depending on your outlook) of errors.

Then finally, one day you decide that the project is a lost cause and stop caring about it. You end up in a "Let's get this over with and get out of here" type of mindset without making any efforts to improve the situation.

In addition to the programming language or theoretical concepts. It is also essential to develop good problem solving skills.

Concepts like design patterns and refactoring would be better taught using hands on exercises based on a long running example, such as having the students create a project in an introductory course on a programming language and then take that codebase as a starting point for the assignments on design patterns and refactoring.

It would be unrealistic to assume that developers would be working only on a single programming language in their entire career. So, a few pointers on how to go about learning new languages based on similarities with programming language(s) they already know would also be there.

Labs in school where we were taught to write small programs in LOGO and BASIC.

Whenever I struggle to explain the working of any code to other team members

1. Finish/start to work on side projects
2. Learn Erlang or something similar
3. Read atleast one book per month (may or may not be related to programming)

Maybe next year, when I attempt to write my first ever friend class...

Probably my language and communication skills.

I tend to think of programming as a conversation between the programmer and the machine.

Similar to being an effective communicator, the key to being a good programmer is knowing what to say when (deciding how to do a particular task, such as reading a file from disk) and not about simply knowing the different ways of saying the same thing (different ways of doing that task in your code).

They know it has something to do with creating and modifying software. That is enough for them and so I am seldom bothered with requests for detailed information.

Also, most often, me working on hobby projects, or just viewing tutorial videos at home is looked upon as "Wasting time playing games".

Then there is also the perception of me being the family's in-house tech support guy.

So that's what it's been up to...

Not writing enough utility programs for those occasions where you have no option but directly modify database tables in production.

Campus interview

Liar's Paradox, Google Assistant version

"Copy the file sent to our warehouse management system to another folder so we can keep track of the deliveries we sent data for."

Why these geniuses think that having a folder with file names containing timestamps (and not delivery numbers) would make their job easier is beyond me...

First go through any getting started guides or introductory tutorials. Then depending on comfort level and available time, either start exploring further on your own or search for more advanced tutorials.

Try to make use of what you learned, either at work or in hobby projects or small proof of concept programs, as the case may be.

Learning Vim is fun (at least that's what Google Play wants you to believe)

A system to keep track of all my side projects, so that I can find enough time and motivation to complete at least some of them (but how will I ever complete this one?).

Being patient and tolerant.

Keep your state of mind to be either one of "This is a lot I can learn from this" or "Let's get this over with, as fast as possible", depending upon the client and nature of work.

The most recent that comes to my mind is from one of my previous projects. Our team is already overloaded and frustrated​ working for this garbage client. One fine day, out of the blue, the client once again revises the list of go-live critical development objects.

Our project manager takes this issue up with the client, and then with our management when the client does not listen.

The response he gets from our management is along the lines of, "But it's just forty development objects. Why are you complaining? Just get it done."

Needless to say, the motivation levels of the entire team went on a downward spiral soon after.

Notepad++. It's good for editing multiple types of files with syntax highlighting. Also doubles as a place for jotting down notes/thoughts without worrying about saving them.

There will always be times when you will need to understand/modify horribly written code, or have to work with a fellow "programmer" who is clueless about what programming actually is.

In such situations, not losing your cool is a necessary evil.

The ability to make developers improve existing libraries/frameworks wherever possible instead of creating new ones every time they encounter a 'Feature X does not exist in library Y' type of scenario.

Film a documentary/reality television series chronicling how A. I.'s eventually self destruct trying to make sense of client requirements.

Management agreeing and then "requesting" to incorporate random client demands.