What is Digital Product School?

Digital Product School (DPS) is a three month training program by UnternehmerTUM where people from different backgrounds and nationalities come together and work in teams of 4-6 people. Each of the teams consists of the following roles: Product Manager, Interaction Designer, Software Engineer, and Artificial Intelligence Engineer. Each of the teams are provided with a problem space from various industry partners. The teams then explore the problem space and develop a digital product to solve real world problems. This whole journey is guided by the core team of Digital Product School to ensure that the teams learn the right approach towards developing a product that solves the targeted problem.

Product Development

The core concept is to conduct user centric development. All the learnings are based around that.

User centric product development is key. Everything revolves around prioritizing user needs. In the end, they are the ones who are going to decide whether the product is worth their time/money or not.

Conduct a lot of user interviews. You have to know what the users’ pain points are. How else are you going to solve their problems? Go out and talk to users. It is also important for the engineers to be involved in this step in order to empathize with the users. Don’t ask what problems they face because it is highly likely that they might say they don’t face any problems because the question bears different meaning to different people. Just talk and try to understand which part of their experience of doing something annoys them.

Observe users. In my opinion, this is more important than asking users a bunch of questions. Because what a user does, says a lot more than what the a user says. Let them show how they go through a process. This gives you a lot more information to make a wise decision. For example, initially we set out to understand users’ problems when they try to buy public transport ticket. However, what we found out is that they struggle more with trying to find out which ticket to buy. So don’t bound yourself by any preconceived notion.

Don’t fall in love with your solution. Constantly validate all the assumptions you make. Your ideas and hypotheses might fail miserably when taken out to the users and tested in real world. Be prepared to change the solution and adapt as you gain more understanding of what the users need.

Fail fast. It is obviously better to know that your idea is not going to work before you invest a lot of time and man hour into developing the product. Paper prototype is your friend. Validate ideas before investing in them.

Keep testing and iterating. While you develop the product, keep going out to the users and test every iteration. When you work obsessively on a product, it is very easy to overlook obvious quarks in the product which become apparent when someone with zero knowledge about the product uses it. Also, testing allows you to get a better understanding of how the users are using the product. Observe their behavior, and adjust the product accordingly.

Ask a lot of why. Users typically don’t know what can solve their problem. At one workshop, we were presented with the following example which I really liked. It goes like this: When people used to ride horse carts, if you would’ve asked them what change they want, they would’ve answered that they wanted faster horses. It is only through asking why they want that, you get to understand that they actually want to reach their destination faster.

Working in a cross functional team

Make tasks visible to the whole team. Put all the tasks on a digital or physical board. This ensures clarity in the team and reduces confusion about who is doing what.

Break down tasks to the smallest pieces. This is especially important for engineers when they are working with people from other functional areas. Why? Because the team mates might not have the understanding that a task like “build login” is actually a bunch of tasks like “build login page”, “build login backend API”, “test login”, “deploy feature”, etc. Breaking tasks into their smallest forms allows everybody to have a more realistic expectation.

Be very specific when defining tasks. Using abstract terms when defining tasks might create different understanding if different members of the team. Since everybody comes from a different background, words can convey different meanings to them. The more specific you are at defining a task, the less confusion it creates.

Resolve conflicts smartly. Sometimes use a democratic process. Other times it might be more important to prioritize the opinions of the domain experts. Be smart about making the judgement.

Leadership is crucial in a flat hierarchy too. The team might start to lag behind, in which case, it is beneficial to step out of your role for a while and make things happen. To the external world, you are a team. What matters is the product that you deliver in the end. So, be prepared to take actions as needed which might be outside your domain.

Retrospectives can be useful to keep the team on the same page. Feedback to the teammates should however be constructive. A nice thank you can go a long way.

Conclusion

This list is obviously not exhaustive. Also, I did not include the technical knowledge I gathered in some new domains, e.g. app development with react-native. I believe it should be an inherent skill of a software engineer to be able to adapt to any given situation and learn whatever technology is needed.

A big “thank you” to the core team of Digital Product School for making it happen. I would strongly recommend Digital Product School to anybody who also wants to improve their skills in these areas.

Few more snaps

• We cannot change the cards we are dealt, we can just play the hand.
• When you are screwing up and nobody’s saying anything to you anymore, that means they gave up.
• Exprience is what you get when you didn’t get what you wanted.
• Head Fake Learning: When we send our kids to play football, swimming or whatever it is, it is indirect learning. We don’t actually want them to learn football. We send them to learn much more important things like team work, perseverence, sportsmanship etc.
• The brick walls are there to stop the people who don’t want it badly enough.
• When you are pissed off at somebody and you are angry at them, you just haven’t given them enough time. Give them a little more time and they will almost always impress you.
• Get a feedback loop and listen to it. When people give feedback, use it.
• Don’t complain, work harder.
• Be good at something: it makes you valuable.
• Find the best in everybody. Keep waiting.
• Luck is where preparation meets opportunity. Be prepared.
• If you lead your life the right way, the dreams will come to you.

Lecture video and slides.

For the past couple of days, I had this question in my mind. Which generates the maximum DPS for a non agility hero - power treads in primary attribute vs power treads in agility?

The reason this came into my mind is that there is a simple trade off between the two scenarios. When you have a hero whose primary attribute is strength or intelligence, switching treads to primary gives you +10 damage whereas switching it to agility gives you +10 attack speed. For agility heroes the answer is that you should always keep it in agility since that gives both attack speed and damage, thus no trade off. However, for the other two types of heroes, the answer is not so simple.

First let’s establish a few ground rules. We are only going to measure the impact of tread switching on DPS for non agility heroes. We are only going to compare the impact of +10 damage vs +10 attack speed, i.e. the impact of switching treads.

Let’s consider a strength hero with treads whose attack damage is AD and attack speed is AS without the treads bonus.

Treads in strength:
attack damage = AD+10
attack speed = AS

Treads in agility:
attack damage = AD
attack speed = AS+10

We know:
attacks per second = (attack speed x 0.01) / BAT
=> attacks per second = attack speed / (100 x BAT)
DPS = attacks per second x attack damage
=> DPS = attack speed x attack damage / (100 x BAT)

When treads in strength:
DPS = AS x (AD+10) / (100 x BAT)
=> DPS = (AS x AD + 10 x AS) / (100 x BAT) … … … (1)

When treads in agility:
DPS = (AS+10) x AD / (100 x BAT)
=> DPS = (AS x AD + 10 x AD) / (100 x BAT) … … … (2)

Comparing equation 1 and 2 we can see that the distinguishing factor is AS when treads in strength and AD when treads in agility. So if we have AS > AD, we want AS to be the contributing factor since it will give us more DPS. In that case, treads should be in strength. On the other hand, if we have AD > AS, then treads should be in agility as AD will then become the contributing factor in DPS and maximize it.

If you are not convinced yet, here is a visualization of the change of DPS based on tread switching for various values of attack speed and damage. Notice the points where the lines cross each other.

You can find the full spreadsheet here.

Asslamualaikum, how are you doing?

I got your email from http://programmermap.com/city/1185241/dhaka.

You are a very busy person I know, yet if you make some free time, please reply back. Your reply will make my day.

I am here for a reason. I hope you will not make me disappointed.

I am a student of CSE dept 1st year 2nd semester. I did very bad in 1st semester and my result was a total disaster. I am trying to improve myself. I thought CGPA will not matter anymore. What is your opinion?

In this semester, I have to do a project in C language and it was really fun for me. So, I decide to learn JAVA and create Android apps. Is it a good decision?

I have acquired some contest programming experiences. I solved 100+ problems in CF and Uva. But my progress disappointed me and I am not doing competitive programming now. My friend circles are the good problem solver, their progress is one of the main reason to make me hopeless. What should I do? I just can’t think, can’t think about my future.

If I make any guilty in my talk. Please forgive me as you are a kind person. Thanks.

Don’t start believing in those bullshits such as “cgpa doesn’t matter” because it might matter. You don’t know yet what possibilities and opportunities you are going to miss out because of poor cgpa. Also it represents your intellectual capabilities to some extent. You are still at the very beginning stage of your journey. Try to achieve a cgpa as high as possible. At some point in your life, cgpa will become irrelevant. But not at this moment. As a student your primary job is to study and your cgpa represents how well you are at performing that job. Whether cgpa matters or not, having a high cgpa won’t hurt.

Developing android apps is fine as long as you have a very strong grasp on fundamental CS concepts. However, being a student of second semester, I don’t think you already have that and I don’t think it is wise to go for any kind of app development, whether android or desktop or web. This is your best time to get your basics right. Learn data structures, algorithms and implement them properly. If you don’t have basic concepts of CS, developing android applications won’t take you very far. If your plan after graduation is to get into the software industry, then know that most of the top tier companies will test you based on the core concepts. Tier 2 and tier 3 companies have a different scenario though.

I would suggest you to focus on competitive programming while maintaining a good cgpa. Competitive programming will prepare you to take on any kind of programming challenge and give you a strong foundation. You will become confident and whenever faced with a programming challenge, you will know that you can solve it. I am reaping the benefits of being a competitive programmer and I can’t stress enough how important it is. Not that people don’t succeed without it. It just makes everything a whole lot easier.

Don’t compare your performance with others. Compare with yourself. Make sure you are improving day by day. Keep making progress. Solve problems regularly. Try new challenges. Attend contests. Up solve problems you failed to do during contests. Keep doing this for at least the first three years. You will be amazed to see your reach after your third year. Then if you feel like moving towards development, do so in your fourth year. Or just continue competitive programming. You will have to do projects for various courses either way.

Losing hope and being disappointed is very common for cs students. What matters is the ability to push through. The difference between professionals and amateurs is that professionals keep doing what needs to be done even if they don’t feel like it while amateurs look for motivation and energy. Have a professional mentality and it will take you a long way.

1. Programmers spend most of the time reading code.

We like to think we spend our time power typing, but we actually spend most of our time staring into the abyss. - Douglas Crockford

2. YOU are responsible for the quality of your code.

Act like professionals. You don’t go to the doctor and say, “I am in a hurry. No need to wash your hands. Just go go go!” Adhere to the professional standards.

3. Use meaningful names.

4. Write code that expresses intent.

5. Comments are often lies waiting to happen.

Code should speak for itself whenever possible.
Code updates don’t often include updating the comments. So comments may become misleading.

6. Leave the code better than you found it.

7. Single responsibility principle.

method: does one thing, does it well, does it only.
class: cohesiveness, are most of the methods using most of the properties?

8. Write tests.

9. Independent architecture.

The software architecture should be independent of the framework it is going to be used with. E.g. a wordpress plugin should be designed such that it can be used independently with minimal changes.

10. Practice, practice, practice.

Learn new techniques when the client is not paying you. Do code kata.

1.

How much of the code is actually communicating and how much is noise? Reduce code size and remove stuffs that doesn’t add value.

2.

Comments often make code noisy.

• Code should be as self explanatory as possible.
• Misleading comments are more dangerous than no comments.
• Comments clutter code.
• Comments are the last thing people look at.
• If a programmer can’t express himself in a programming language, he is less likely to be able to express himself in a natural language.

3.

Sustainable spacing

3.1

Lines should not go beyond 80 characters.

• Reading narrow columns from top to bottom is comfortable, like the newspapers.
• Developer might write code using large monitors, but someone reading the code might use any kind of device.
• Important information might reside at the rightmost region of the line.
• Code reviewers might use tablet.
• Narrow lines is universally suitable for most devices.

3.2

Code should visually convey information. When things are aligned, people assume somehow they are related. So similar stuffs should be aligned.

Positioning argument list

How not to:

public int howNotToLayoutAMethodHeader(int firstArgument,
    String secondArgument)

How to: Group arguments together, better readability

public int howToLayoutAMethodHeader(
    int firstArgument,
    String secondArgument
)

Don’t do this:

public int doNotDoThis(int firstArgument,
                    String secondArgument);

Because this is unstable, alignment breaks when refactored.

public int unstable(int firstArgument,
                    String secondArgument);

These are not prone to breaking alignment when refactored.

int thisIs =
    stable(
        someArgumentOrExpression,
        anotherArgumentOrExpression);

int andThisIs = stable(
    someArgumentOrExpression,
    anotherArgumentOrExpression);

Positioning curly braces

Don’t do this: Visually unclear where the body of a block starts.

public ResultType arbitraryMethodName(
    FirstArgumentType firstArgument,
    SecondArgumentType secondArgument,
    ThirdArgumentType thirdArgument) {
    LocalVariableType localVariable =
        method(firstArgument, secondArgument);
    if(localVariable.isSomething(
        thirdArgument, SOME_CONSTANT)) {
        doSomething(localVariable);
    }
    return localVariable.getSomething();
}

Do this:

public ResultType arbitraryMethodName(
    FirstArgumentType firstArgument,
    SecondArgumentType secondArgument,
    ThirdArgumentType thirdArgument)
{
    LocalVariableType localVariable =
        method(firstArgument, secondArgument);
    if(localVariable.isSomething(
        thirdArgument, SOME_CONSTANT))
    {
        doSomething(localVariable);
    }
    return localVariable.getSomething();
}

Or this:

public ResultType arbitraryMethodName(
        FirstArgumentType firstArgument,
        SecondArgumentType secondArgument,
        ThirdArgumentType thirdArgument) {
    LocalVariableType localVariable =
        method(firstArgument, secondArgument);
    if(localVariable.isSomething(
            thirdArgument, SOME_CONSTANT)) {
        doSomething(localVariable);
    }
    return localVariable.getSomething();
}

4.

Naming should be simple, small, precise

4.1

Reduce names with redundant information. Stop trying to dance around the name, just say the name.
Don’t:

public interface ConditionChecker
{
    boolean checkCondition();
}

Do:

public interface Condition
{
    boolean isTrue();
}

4.2

Meaningless words: Object, Thing, Component, Part, Manager, Entity, Item. How much of a name is left when you remove all of these words?
Example: Putting the word Exception behind every exception is bad. Because it is obvious that something that comes after a throws statement is obviously an exception. Exceptions that indicate something bad happening doesn’t require the word exception in the end.
AccessViolationException \(\rightarrow\) AccessViolation
IndexOutOfRangeException \(\rightarrow\) IndexOutOfRange
InvalidOperationException \(\rightarrow\) InvalidOperation

4.3

Name exceptions using the problem so that it becomes obvious even without the word Exception.
ArgumentException \(\rightarrow\) InvalidArgument

5.

Missing abstraction: Code in the language of the domain.
Don’t:

if(portfolioIdsByTraderId.get(trader.getId())
    .containsKey(portfolio.getId()))
{
    ...
}

Do:

if(trader.canView(portfolio))
{
    ...
}

6.

Don’t provide setters if only getters are needed. Getters don’t necessarily need the word “get” because sometimes its redundant.

public class Money implements ...
{
    ...
    public int getUnits() ...
    public Currency getCurrency() ...
}

Better:

public class Money implements ...
{
    ...
    public int units() ...
    public Currency currency() ...
}

Getting something is an imperative statement in English which means having some kind of side effect.

7.

The most important word in TDD is “driven”. Are tests driving the development?

As I was calculating the number of matches I need to play to increase my mmr by 1K at a particular winrate, the idea of creating a graph to visually feel the change of required number of matches at different winrates, came up. So I created the following graph by generating all the required number of matches for both +500 and +1000 mmr change. I hope this will help all the mmr ladder climbers realize how much time they have to put in for their desired mmr increase at the level that they perform (winrate).

On the X-axis we have winrate and on the Y-axis we have required number of matches. The blue and the red curve are for +500 and +1000 mmr increase respectively. The formula for calculating required number of matches is pretty simple.

mmr_net_change = mmr_per_match * no_of_matches * winrate
                 - mmr_per_match * no_of_matches * (1-winrate)

Rearranging this we get:

no_of_matches = mmr_net_change / (mmr_per_match * (2*winrate-1))

Here you can see the whole chart that I calculated for winrates in the range of 51% to 70%.

Hope you guys plan your journey accordingly.

Disclaimer: This is by no means a comprehensive guide to git and github. The tutorial is simply to show beginner programmers and problems solvers how they can use git and github only to back up their codes. Git and github are a lot more than just backup tools. But that’s not the focus of this tutorial. So if you are already a pro in version control systems, this guide is not for you!

What is git and github?

Git is a version control system. What it does is keep track of changes in files so that later you can specifically recall which version you want to check out. For example, you might have a bug free (!) working software. Now you want to add a new feature. So you start coding the new feature and at some point, you find out that you have broken the software by changing something that was stable before. You start to panic as you don’t know how to get back to the previous stable version. How git helps here is that when you have a working stable version, you can make a commit i.e. create kind of a restore point and then start working on the new feature. If you break the software you can come back to that restore point any time you want. This is all you need to know about git  at this point.

Github is an online project hosting platform using git. You can use github to back up your local projects in an online repository. Github is primarily used for collaborative projects. Many open source community projects are hosted on github and programmers from all around the world contribute in them using git. However, you can also use github just to back up your codes in your own repository!

Why git and github?

Now you might ask, why git and github when you can simply drag and drop the files in a google drive folder! Getting to know and using new tools might seem intimidating at first especially when you start to see commands! (Yes we will be using commands in the terminal/command prompt.) So we must get some value out of it otherwise why bother making things complicated, right?

First of all, we are programmers. We should use tools built for programmers. I understand it’s not a good enough reason why you should use git. But here’s the thing, as I have mentioned before, git is not just a back up tool. It’s a version control system. When you start working in large projects, especially when you work in professional environment and collaborative projects, you must know how to use a version control system. Hundreds/thousands of programmers working on the same project making changes here and there - can you imagine the scenario? How do you manage all that? Does google drive seem enough? No. You need more powerful tools and git and github together makes such a package.

Since you will have to use it at some point, why not take the opportunity to get used to it from now on? Start using git for the basic purpose of backing up. As you keep on exploring, you will figure out the beauty of it. If you are a student at this point, then later you can use it for group projects. You won’t need to transfer code using pen-drive or facebook messenger or emails! So start using these tools.

The real stuff

Let’s dive into how you can use git and github to back up your codes. There are lots of resources available online on git and github. They are really well written. You can also find video tutorials. Here I will help you establish a workflow to back up your codes and point to those resources for detailed procedures.

Install git

First you need to install git. Here you will find how you can do so on any platform.

Create repository

As you have installed git, now you need to turn your project directory into a git repository. The project directory can be a directory where you are coding your software. It may also be the directory where all you competitive programming solutions are saved. Since I am going to demonstrate the back up functionality of git and github, I will use competitive programming solutions for the tutorial.

Let the directory that holds all the competitive programming solutions be “competitive-programming”. Open terminal/cmd and go to that directory using the “cd” command. Now initialize this directory as a git repository by simply running the following command.

git init

This command will create a directory called “.git”. This will hold all the information related to this repository that you just initialized. If you no longer want to keep the directory as a git repository, simply delete the “.git” directory. Yes, it is as simple as that.

Add files

Your “competitive-programming” directory is now a git repository. Now you need to add files to the git staging area. It’s nothing complicated. This step simply tells git which files to keep track when you create the next restore point. In order to add all the files in the repository, run the following command (the dot in the end is in the command).

git add .

If you want to select which files you want to add, then run the command like this.

git add file1.cpp file2.txt file3.py

If you want to ignore a directory or a whole class of files like all the executable files, then you need to create a text file called “.gitignore” in the repository. You can find details here but for now you don’t need to think about it too much.

Commit

After adding the files to the staging are, you have to make a commit. This is where the restore point gets created.  A commit has to have a message with it which indicates what this commit signifies i.e. what changes have been made. To back up competitive programming solutions, you don’t need to care much about this message. Just type in something! Here’s the command.

git commit -m "your commit message in quotation marks"

At this point, you have locally tracked your files. You can see all the past commits using the following command.

git log

This shows too much details. A concise log can be seen by the following command.

git log --oneline

Actually backing it up!

Now you need to back up in github. First create a github account. Then create an empty github repository. For our case, we will name it “competitive-programming”. In the newly created empty repository, you can see a section named ”…or push an existing repository from the command line”. This is what you will need to do and let me explain what’s going on here.

Add remote

The first command is to add remote. Remote means a repository that is located in a remote server i.e. not in your local disk. You have created a local “competitive-programming” repository. What you need to do is add a remote repository for that local repository. Here, your newly created github repository is going to be the remote repository. By convention we name the remote repository “origin”. So in you terminal, go to the local repository and run the following command as you can see in the github page.

git remote add origin link-to-the-new-empty-github-repository

Push code

You have added the remote repository. Now you need to push the local files to the remote repository. Run the following command.

git push -u origin master

This command pushes your local repository to your remote repository named origin. The master at the end of the command indicates the master branch. You don’t have to care about it at this point because you won’t need any other branch except the master branch. Branches are used in large scale projects to develop different features. You might need to enter your github username and password as you run this command.

Victory!

This is it! Refresh the github repository page in your browser and you will see the files backed up there. This is not that complicated. Once you have initialized the repository and backed up the first time, you won’t need to do all these any more. From there on, it will be just a few commands to back up your code.

For example, let’s assume you have done this whole thing. Now you have your codes backed up and the whole repository thing set up. Now you have solved some new problems. To back them up, simply open up the terminal in the “competitive-programming” directory and run the following commands.

git add .
git commit -m "backup"
git push -u origin master

There you go, your latest solutions are also backed up! As you do this over and over again, it will become intuitive and you won’t even need to think about it. This is what you should do instead of using google drive or any other drive. Getting used to version control system such as git will save you from a lot of trouble and help you in the long run. So explore git and github and start using them. Do collaborative projects using them. This will take you one step ahead.

Feel free to contact me if you need any kind of help!

I modified the program a little bit in a way that I incorporated some isolation training for biceps and triceps which are not in the program. I began with light weight based on my calculations of where I was going to get after one month. Reason behind selecting one month is that it was the month of Ramadan. The gym is less crowded during this time of the year and people won’t be waiting for instruments as I do the workouts. According to plan, there were 12 workouts. So 12 workouts of squat and 6 workouts of the other exercises. Considering an increment of 2.5 kg or 5 kg per workout I calculated which weight I should start from. I started the program on 11th June and here’s the whole journey of session 1.

** All weights are in kg and without the weight of the bar. The bar weighs around 17-18 kg. Just add 17-18 kg with the weight mentioned below to find the total weight. Standard bars weigh 20 kg. The reason behind 17-18 kg is that the bars have deteriorated over time. Also I didn’t include warm ups in the log.

Day 1 - 11-Jun

Squat: 30 kg, 5/5/5/5/5
Bench press: 20 kg, 5/5/5/5/5
Dead lift: 50 kg, 5

I was very much comfortable with all those weights. I know what you are thinking. They are very light. I am a beginner here and I didn’t want to ruin my journey by starting with ego lifting. So I started small and looked forward to increasing weight on each workout.

Day 2 - 13-Jun

Squat: 35 kg, 5/5/5/5/5
Overhead press: 10 kg, 5/5/5/5/5
Bent over row: 20 kg, 5/5/5/5/5

Still the weights were pretty light to me. However I started to feel some pressure during the finishing reps of the final set of squat. I incremented squat weight by 5 kg because 30 kg was too light for me. I will do the same in the next workout. It was a good solid workout.

Day 3 - 15-Jun

Squat: 40 kg, 5/5/5/5/5
Bench press: 25 kg, 5/5/5/5/5
Dead lift: 60 kg, 5

I started to feel the weights. All the exercises were hitting the muscles. The whole workout felt great!

Day 4 - 17-Jun

Squat: 45 kg, 5/5/5/5/5
Overhead press: 15 kg, 5/5/5/5/5
Bent over row: 30 kg, 5/5/5/5/5

I increased the weight on bent over row by 10 kg because last time I did it, it felt too easy. Even with 30 kg I did pretty good. The squats became difficult towards the end. I found most difficulty in the overhead press. I struggled to get the last repetition.

Day 5 - 19-Jun

Squat: 50 kg, 5/5/5/5/5
Bench press: 30 kg, 5/5/5/5/5
Dead lift: 70 kg, 5

The weights are getting heavier. I am starting to struggle. This is exactly what I need!

Day 6 - 23-Jun

Squat: 52.5 kg, 5/5/5/5/5
Overhead press: 17.5 kg, 5/5/5/5/5
Bent over row: 35 kg, 5/5/5/5/5

Before this workout, I had a little bit of back pain due to bad posture. After working out, the pain was aggravated. I am not sure if I can do the next workout properly. May be I have to reduce weight, or do alternate exercise that don’t involve the back so much.

Day 7 - 25-Jun

Leg press: 150 kg, 5/5/5/5/5
Bench press: 35 kg, 5/5/5/5/5

My back was hurting. I decided not to do squat as it puts pressure on the back. Alternatively I chose leg press. I  completed leg press and bench press properly. Then I didn’t do dead lifts for the aforementioned reason. Instead, I did some bodybuilding chest exercises. I did inclined dumbbell press and dumbbell fly.

Day 8 - 30-Jun

Squat: 55 kg, 5/5/5/5/5
Bench press: 37.5 kg, 5/5/5/5/5
Dead lift: 75 kg, 5

My back pain was causing me a lot of trouble. So I decided to take a break for a few days. Then I started again from where I left off. Squats were tough even though I accomplished them. I struggled with bench press a lot. I needed support from my partner to complete all those repetitions. I was fine with the dead lift.

Day 9 - 3-Jul

Squat: 57.5 kg, 5/5/5/5/5
Overhead press: 20 kg, 5/4/5/5/5
Bent over row: 35 kg, 5/5/5/5/5

I am happy about my squats. I have been able to increase weight consistently. I struggled with over head press. I couldn’t lift properly in the second set. I stopped at 4th rep. I took support for the next 3 sets. I could’ve increased weight on the bent over row. However the last time I did it, it caused me back pain. So I didn’t want to increase.

Day 10 - 5-Jul

Squat: 60 kg, 5/5/5/5/5
Bench press: 40 kg, 5/5/5/5/5

Unfortunately I didn’t have enough time for this workout. So I had to skip dead lift. I am satisfied with the squat performance. However my bench press needs a lot more work. I had to take support from my partner to finish all those sets and reps.

Conclusion

I must say it was a wonderful journey. Unfortunately I couldn’t do it for the total of 12 days due to the injury I mentioned above. I also didn’t finish all the workouts properly. Most of the gains are newbie gains. After the eid-ul-fitr vacation I am going to resume the high volume workouts. I track all the workouts in fitocracy. I am definitely going to do stronglifts in future. From my experience, I highly recommend it to the beginners.

Here is the final picture (in kg without bar weight).

Squat ------------------------- 30 ----> 60 ---- +30
Bench press ------------------- 20 ----> 40 ---- +20
Dead lift --------------------- 50 ----> 75 ---- +25
Overhead press ---------------- 10 ----> 20 ---- +10
Bent over row ----------------- 20 ----> 35 ---- +15

Sabit

I want to start the review with one of the most disturbing and heart breaking incident of this year for not only me but also my classmates. This year my very good friend Sabit left us. One of the brightest humans I have ever come across and spent time with felt like this world has nothing to offer. It was 15th of May when he finally decided to let go of every attachment. It was a nightmare for us. First boy in our class, highest CGPA holder, sound programmer, extraordinary footballer winning best player of DU, musician playing drums and guitar - none of this ultimately mattered to him. We failed to make him realize how precious he was. I dearly request everybody to wait and figure out what life has to offer before you come to any hasty conclusion.

What went well?

• I learned that “Ferrero Rocher” is pronounced as “Ferrero Roshey”. Thought it would be interesting to many of you!
• For the first time, I was involved in Saraswati puja. It was a trivial involvement. I just helped our hardworking Jagannath Hall dwellers with packing fruits!
• For the first time I entered machine code directly into any machine. In this case it was an 8086 emulator.
• I became a voter in 2012 I think. This year I voted for the first time. Although I don’t think the vote actually mattered because you know, Bangladeshi politics, winners were predetermined. Still something to remember.
• We arranged another Pohela Boishakh event from the CSEDU Students’ Club successfully.
• Intra department football tournament was held again. We had six teams participating. Two from 19th batch (we have lots of footballers!), three from the other three batches and one from the alumni. We were the defending champions. However we failed to retain our title and became runner up. Congrats to 20th batch on winning the championship.
• Didi came to Dhaka this year after a long time. We, the cousins went out and spent some wonderful moments together.
• In the Software Design Pattern course, we had a project to finish by the semester. We (Zahin, Towhid and I) worked on building an web application which basically is a community blog platform. It is not a fully functional website. However, this is the first web application we have ever made. So being able to achieve a working app was a win I think. Here’s the project page.
• Tonmoy dada got married this year and on that occasion, I had a visit to Nator this year. Spending time with cousins together had always been fun for me. This year it was not any exception.
• Sylhet tour was something I will remember for the rest of my life! A gang of 18 from our batch went with the main goal of visiting Hum Hum waterfalls. It was a tremendous journey visiting Bichanakandi, Ratargul, Madhobkundo, Shrimongol. On the final day we visited Hum Hum. Those of us who went pushed their limits. All of us had to get out of our comfort zone and it was a wonderful experience.
• Tasted pepper tea for the first time at TSC. I highly recommend everyone giving it a go.
• I tried out the disconnected under cut this year. I usually don’t go for any unorthodox haircut. However trying it out was a nice experience. Might do it more in future.
• I used to blog in 2013 when I wrote in my programming tutorial site (binaryrongo). But I had a huge gap after that year. I came to realize that writing tutorials helps me understand those topics more deeply. Also since different readers ask for tutorials on various topics, I need to learn those and thus it helps me grow. So I have decided to write blog posts regularly. Also I figured out that I should keep a personal blog, a hub where I can share my thoughts and people can find out about me.
• A major win for me this year was the networking project. This is the first project that I felt so satisfied after being able to finish it up. The reason behind it is that none of the effort that I put into it went in vain. Every bit mattered. It is a replica of the popular TeamViewer app. We (Ratul, Sabah, Mehedi, Tanim and I) were able to build something that works as it should. More importantly, I learned so much from this project! Here is the project page for more details.
• I have been playing dota for quite a while. It occurred to me that I should try to increase my MMR and so I created a new account and reached 2.6K. I think this is what I deserved. Let’s see where it goes in the upcoming years.
• I have decided that even though I should try to increase my ratings in different competitive programming platforms. Attending contests regularly and upsolving should help in the process. So I have already started to try to attend Codeforces regularly. I will move towards Topcoder, Hackerrank and other platforms as well.
• Another major win this year was joining the gym again. I was able to shred off a about 6-7 kgs of fat! I am a lot leaner now.
• I achieved the milestone of doing a total of 100 push ups in a day. Well to be more specific in about half an hour. I have plan to reach this mark in around 10 minutes.
• I increased my ab workout intensity. I did a total of 100 ab crunches, 100 lying leg raises, 100 lying hip raises and 100 ab twists in one workout.
• This year for the first time I was able to do a complete pull up. Now I can do about 5/6 pullups in one go.
• I saw a mainframe computer for the first time. Most of us didn’t even know that there is one in our own department!
• Onu attained GPA 5.00 in PSC exam with a 5.00 in every subject. It was a major win for him and also a proud moment for our family.
• I improved my diet and nutrition to have more meaningful food rather than just eating for the sake of eating!

What didn’t go so well?

I started 2015 with a major goal of focusing on competitive programming. However in the middle of the year, I shifted my focus away from it. I decided to stop taking it seriously and rather do it in a casual manner while exploring other domains of CSE. Sadly, I didn’t make much progress in the latter. Now I am planning on taking competitive programming a little bit more seriously.

This year I didn’t attend gym as regularly as I should have. Fitness is something I encourage everyone in. But I was lazy or procrastinated more often than I should have.  Also I had made a few resolutions in the beginning of the year 2015 which I failed in achieving.

There were a few personal issues also which are better left private.

Conclusion

Like any other year, it was a mixed experience. What matters is what I have learned from all the experiences I have got and whether there is a reflection of that in my future. I must say that I have improved and turned into a better version of myself comparing to what I was in the beginning of the year.