Sunday, January 25, 2015

Bitcoin: What's the big deal?

TechTalk Summary: The intention is to understand a topic by raising and answering questions by participants, all of whom are interested in exploring the topic further. Most of the discussion is performed by novices in the field, so most progress is based on first principles. And there could be technical faults in the discussion captured below.

{ This is Part 2 of the Bitcoin TechTalk series. The previous TechTalk about Bitcoin is available here: Bitcoin: A Bubble? }

A: So new currency you say, why do you need a new currency?
B: It is a decentralised network, there is no central authority. So a central authority cannot ask you for a high percentage of commission. A network of miners maintain the network and they are rewarded by new bitcoins for their work.
A: Well, that is for now. Once the transaction volume increases,who is to stop them for charging high commission?
B: Well since anyone is free to participate in the miner network, hopefully economic/competitive equilibrium is reached.
A: Hmm... but if anyone can participate in the miner network, how do you avoid malicious activity?
B: That is the crux of the bitcoin algorithm. It maintains a distributed ledger of all transactions since Bitcoin's birth. Adding transactions to this ledger requires high computing power. And every miner in the miner network is in a race to add transactions to this ledge. On the other hand, validating transactions from the ledger requires very few computational resources. So it is easy for the miner network to identify and discard malicious transactions.
A: While the distributed ledger in itself is useful in a lot of situations beyond currencies, the very low transaction charges implies that you could perform very small transactions without incurring much cost. A slew of new and interesting ideas could be implemented with this. (Ref: Why Bitcoin matters)
B: But the cost of bitcoins is too high, I don't think micropayments is an option at all.
A: Actually, the bitcoin protocol has a nifty feature where you could divide a bitcoin down to as small a fraction as you wish. Currently the smallest unit of bitcoin, also called a satoshi, is 1/100,000,000 BTC



Thursday, January 22, 2015

The urge to do

Programming and debugging are  activities where we should think a lot and do little. Commonly what happens is the reverse. We are driven by the urge to do something.

It's particularly true for debugging. We see a  problem, the first instinct is to print something, build and rerun. And then print some more. In the end when we discover the problem we go: Ah, that was obvious. I could have gotten there faster instead of these x iterations. And on complex systems these iterations take a long long time.

It often helps to resist the urge to do  and think what could be going off here. It saves a ton of time.

So also for programming.

A lot of programming time is spent in the edit build debug cycle. We make numerous iterations through this cycle to get to our goal. How could we optimize this? What if we are allowed only 1 iteration through this?

To ensure that I put enough thought in the process, recently I created this game for myself. After breaking the problem into subproblems I take it as a challenge that every submodule that is built will run completely in the first iteration itself. I get to decide the size of the submodule, but my code should do exactly what I intended in the first shot. Over time I have found that this leads to a lot of efficiency by forcing me to think of all the dependencies and side effects upfront.

Of course not all problems can be addressed with this method. Especially if it's a new technology or domain you learn much faster through each iteration. But for a lot of cases this approach does magic. You should try it out...

Saturday, January 17, 2015

Bitcoin: A Bubble?

TechTalk Summary: The intention is to understand a topic by raising and answering questions by participants, all of whom are interested in exploring the topic further. Most of the discussion is performed by novices in the field, so most progress is based on first principles. And there could be technical faults in the discussion captured below.

[ Please contribute in the comments section, that is the place for most revelations / insights ]
  • A: Why does its value fluctuate?
  • B: Same reason why the value of any other commodity or equity shares fluctuate.
  • A: What is it backed by? Equity shares have the products created by the corporation or its assets as its backing?
  • B: I don't think its backed by anything per-se. Even in case of corporations, the perceived value as reflected in the market capitalization wouldn't always match the assets or the created products. 
  • A: All currencies are usually backed by gold, aren't they. There is no such backing for bitcoins. Could the energy spent in mining the bitcoins the backing for bitcoins?
  • B: True that. That makes it seem like a bubble. I don't have anything to show for it when things are going south. The energy spent is actually energy spent, I still don't have anything to show for it.
  • A: Actually, what happens if the price of gold itself goes down, what do we have to show for that? An ornament?
  • B: Let's go back to the time in human civilization where only food and wood (shelter) was required for survival. At that point, what would be the value of gold, nothing. I can't eat it, I can't use it for shelter. It's as good as stone. It's price rose only when multiple people were interested in it.
  • A: And it was scarce enough. Demand-Supply. As long as you have demand, the value will be maintained. So yeah, apart from food and shelter everything else is pretty much perceived value driven by demand-supply.
  • B: The supply is throttled at about 25 bitcoins per 10 minutes for miners, so that addresses the supply side
  • A: I wonder what is the number of bitcoin owners. If all of them together dump bitcoin, only then the demand will go down. 
  • B: Hmm, that will affect the value of bitcoin, but we could still continue to use it as a medium of currency exchange. 

Some links that I search after this discussion:

Fresh Minds == Fresh Ideas

Seems quite obvious but very hard to follow...

Once we are working on something for an extended duration of time, the base assumptions get latched on to our mind. We continue to be actively focused and working towards our targeted milestones, ignoring these along the way. It takes a fresh mind to question these assumptions. Only then do we realise 'Ouch, that is no longer true...'. We have to continue to flush/revisit these base assumption.

That's why we stumble upon debugging clues when we discuss the problem with someone.

That's why we have a deeper understanding of a subject when we teach it to someone.

So if you care about innovation, if you care about questioning the status-quo, ensure you encourage fresh minds to contribute ideas openly. Make it an integral part of your organization's culture. Ensure every idea is evaluated on the merit of the idea than that of the proposer.

Thursday, January 15, 2015

This is *your* project

That is clearly the most repeated message when we guide projects for the Dreamz Group.

In our minds, ever so slightly, we stop being in the driver's seat. But the reality is, its just us, it is our project. Others will help us, they guide us, but its us who decides where the car is going.

And it happens at work too... You are knee deep in it, you have to drive it. Everyone else has only a limited perspective, however experienced they are. Take the right calls, raise the right issues.

Older Blog's Archive

My earlier blog was hosted on kerneltrap. Now that the site is down, this blog can be accessed using the awesome WayBack Machine from here: https://web.archive.org/web/20130111015250/http://kerneltrap.org/blog/3986


Monday, February 13, 2012

Why work (hard) on a BE Project?

(Originally published at http://thebeproject.blogspot.in)

(Note: Although I mention BE Project below, this applies to any project that you are working on during your student days. )

Answer some questions for me:
1. What programming language are you strongest in?
C, C++, Java?

2. How complex a program have you written in this language? Any programming beyond the assignments?

Programming is what you are going to be doing for a long time in your career. How have you really prepared yourself for this? Scoring well in theory exams is in no way an indicator of how well you can program.
Lets take cricket to emphasize the point further:
a. People who score excellent in cricket theory exams cannot become cricketers. They will tremble and sweat standing on a pitch when facing a fast bowler. A situation not unlike many I have seen in IT companies.
b. Excellent cricketers have spent a long time practicing on the pitch. You are automatically comfortable, you know you are on your home pitch. You may be nervous, but clueless you are not.

Of course, I don't mean theory is not important. It is crucial. But so is programming, and unfortunately our examination systems, do not quite test you well on that. Thankfully, within the first 10 minutes, a good interviewer can identify a kaun-kitne-paani-main-hain... (This gets quite close to the point I am trying to make).

3. Do you think after 4 years of your BE, you are a mature technical professional who is hireable?
Towards the end of my third year, I always thought we have hardly done anything significant during Engineering. I mean anyone reading a few books can get here. What makes me different?

Here are some of the important benefits of a great Project:


1. Choose your co-workers, choose your work

This is something which is closer to the hearts of the students and so lets look at that first.
Rarely in life do you get a chance to choose your co-workers. This is a golden opportunity to work alongside your friends on something constructive. Many of my students often remember and miss their days of the project when they were designing for their project, brainstorming an idea or hunting for a bug for days at end.

The culmination of all these gives you a high, a sense of achievement, like nothing else. Its that feeling of accomplishment that stays with you.

Not only your co-workers, but this is also your opportunity to choose your domain of work, or pick an idea that you are passionate about. Many people that I know end up working in more or less the same domain that they did their BE project in, , even after years of passing out of BE.

2. Preparing for the future
Here are a few things that you'll be doing once you join any organisation
a. get familiar with the tools
  - revision control system
  - bug tracking system
  - development environment
  - netiquette
b. get familiar with the code
  - understand the existing architecture, code base
  - debug and fix bugs
  - design, implement and test a component


And this is going to be your profession. Surprisingly, as a student you have never had to do any of the above during your engineering. The academic assignments are too small to count towards this.

Your project acts as the sufficiently complex entity where you can get to experience all of the above first-hand. You yourself have to consider the breaking of problem into sub-problems, scheduling, risk mitigation and other strategies. These no longer stay concepts from Pressman, but you get to put them in practice. As you experience these concepts, you start developing ways and procedures of dealing with problems yourselves. This is the important learning curve. This is what contributes to the "experience".

There are many things that you can learn and absorb during the various phases of your project. We'll cover that probably in another article.

3. Foot in the door
The resumes of most BE passouts are just about the same. As I mentioned above, good marks aren't necessarily an indicator of mature developers. So how are you different from the thousands of engineers passing out with you?

Your BE project acts as your foot-in-the-door. That is what separates you from the rest. Working on your BE project also counts towards your experience in that particular domain. You now have something more concrete to talk about in the interview, and having spent time on that you are an expert in that field.



Acknowledgements: Thanks to Amey Inamdar and Amod Jaltade for their suggestions.

Wednesday, November 25, 2009

Wednesday, June 03, 2009