PREFACE - abukhalil-LTUC-ASAC/amman-401d4 GitHub Wiki

Here is the catch

Your path ahead is full of roadblocks, and its not up to anyone but you (along with some help from others) to navigate through it. One of these roadblocks in Software development is burnout, and it sometimes comes from having mental exhaustion on the daily basis, I have always compared it to farming and other labor intensive crafts. The key to avoiding it is to take the process to heart, as what is sometimes called being Process Oriented, the other is having grounded expectations of what is currently possible but that is not something I can tell you about.

So lets dive into other expected roadblocks.

Interviews

Believe it or not, your whole career at a particular company might come to the fact that you mispronounced a word that sounded awful at the interview, ask the experienced on that (ehm.. me). First impressions, cohesive arguments and structured thoughts will go far enough, but preparing for these usually involve lots of previous attempts and practice within social context.

Software Development involve an additional element which is code test/review, of which even more failure tend to happen due to the following factors:

  • Time flies by as you write code.
  • Code flies by as you attempt to solve problems without thinking about it at first.
  • Patience flies by as you have no interactions or conversations with the interviewer during the test. These three represent the bane of programmers due to the solitary time they mostly spend solving problems without asking for much help or interactions with others, and reflect how poorly they might solve these problems on a regular basis at work.

The article does a great job at breaking these problems down to a proven method that could help you along, which are summarized as:

  • Read the problem completely twice.
  • Solve the problem manually with 3 sets of sample data.
  • Optimize the manual steps.
  • Write the manual steps as comments or pseudo-code.
  • Replace the comments or pseudo-code with real code.
  • Optimize the real code.

Why problem solving anyway, and how?

Because at the core of life is a bunch of problems whenever you attempt anything at all. At the core of what computer programming is, to move physical world solutions and implement them on a machine level, and to do that you have to understand how the machine thinks, which is the problem of translating between what is physical, and what is machine.

Most of us might have played "some" games, and have found out conclusively that there is always a solution to a problem in puzzles and other domains such as money making, but it mostly revolves around mindlessly throwing possible solutions around until something sticks! Which is a major source of frustration but also as rewarding and addicting. I have always admired E-Sports in their dedication to perfect a skill by repetition, but most importantly with those who rise quicker than the rest and seem to pick up these skills easier. These have found the way to do [Deliberate Practice}(https://jamesclear.com/deliberate-practice-theory), and managed what athletes and world renowned achievers have been doing all along but you were not able to see on a daily basis.

Software Development has their own possible ways of improving problem solving methods. The following article has some explained in the form of getting the right framework at place and turn it into habitual thinking.

  • Understand, by explaining it
  • Plan, as in whiteboard and team/client discussions
  • Divide, as in divide and conquer (thanks rts)
  • Stuck? take a nap, talk to google, then talk to the team.
  • Practice with coding challenges is one way, another is continuously asking for more challenging daily tasks as you go through them,

What about looping problems?

Now before you ask, yes its about problems that keeps occurring every damn time. For code errors I have taken aback of how useful most error logs are, sometimes a subtle word such as failed promise in a 300 line error is all that you would need. Other non obvious errors involve logic processing that requires line by line debug.

A more systematic approach when dealing with system wide erros (aka bad implementation, misunderstood customers etc) have their own set of solutions you could follow, the third article of today mentions them as the following 5 WHY's in seven steps, don't ask why.

  • Assemble a Team, as in the right men/women for the right job at the right time
  • Define the Problem, some advanced problems involve the following ("Team A isn't meeting its response time targets") and such on optimizations and delivery.
  • Ask the First "Why?" as in Why isn't Team A meeting its response time targets?.
  • Ask "Why?" Four More Times by going to the problem at a deeper level, it might be management, the management might be having too much holidays, main guy in management just had a divorce and such.
  • Knowing when to stop, as in no further why would produce useful information, why did he had a divorce is of no one's business.
  • Monitor Your Measures, if providing enough ink for the printer did not solve it, remove it from consideration.

If you are thinking about how much you are worth, take a look at the final article

It is not as much as how much you could do in a week, if most of the rest of it goes unproductively. Now it is not about being a 1000% efficient robot either as you have your own needs and well being to tend to in addition to your surrounding environment/family/community.

What the article emphasizes on delivering value, and to do that from a non value position, it attempts to convince you to "fake it till you make it" but not in a way that would allow you to fake being a doctor for an example. It is much simpler and involves putting bad habit aside and trying out better ones. Time is not a currency and you should treat it as invaluable as you possibly think of, which is initially at 1000 dollars per hour assuming you are not even close to 5% of that value.

Now how you would move into that state pretty much depends on your current one, a pronounced software developer could take up clientele as an advisor and starts charging that amount in a very short amount of time. What you choose to do is up to you, just aim high with each passing hour and don't forget to get a better bow/projectile throw machine along the journey.