Sie sind auf Seite 1von 6

Algorithms

What is an Algorithm
An algorithm is an effective method for solving a problem. Algorithms date back to early 300 B.C.
and apply in a wide variety of areas today, ranging from mathematical, physical, astrophysical,
logical, statistical, financial, biological etc.
-

A developers occupation is to develop algorithms, to solve problems.


Algorithms are used as part of a systematic process, to devise computer programs that
solve problems effectively and efficiently.
Most algorithms typically studied in CS classes may not have as much application on the
web nowadays, but the process of generating them does have application, immensely.

Methodology
ALGORITHM
DATA
OPERATORS

INTERMEDIARY
DATA (OPERANDS)

INFORMATION
OPERATORS

PROCEDURES

PROCEDURES

FUNCTIONS

FUNCTIONS

Systematic Process
1.
2.
3.
4.

What do we have? Data


What do we need? More data & intermediary (processed) data
What do we want? Information, results
How do we get there? What is the next step, step by step, using data

Example
Problem: We need to have fresh water readily available in a portable fashion.
-

What do we have? A river in the back of our house


What do we need? A water bottle, a cap for the water bottle
What do we want? Problem above
How do we get there? By filling the bottle with water from the river.

There are multiple ways of filling the bottle with water.


If we hold the bottle against the river, as straight as possible, with half of the opening facing
upstream, the bottle will fill with water, while allowing air to escape. This solution is effective, but
is not efficient for two reasons:
-

Only works in moving waters


In stationary waters we have to run the bottle against the water surface
Requires a steady hand
Is likely to take more time than other methods

Intuition tells us that air is lighter than water, so we can simply sink the bottle in the river, and
air will escape from the bottle naturally, allowing the bottle to fill with water. This is more
efficient than the first method because:
-

Only works in moving waters? no


Do we have to perform additional actions in stationary waters? no
Requires a steady hand? no
Is it likely to take more time than other methods? the only performance bottleneck is the
actual bottles neck.

Can our solution be transformed and scaled up to any liquid, any location on a planet, any water
size, any bottle capacity? Sure.
We have identified, through intuitive reasoning, that this is the optimal solution. We can now tell
a robot to do it:
Robot.extendArm();
For (var I in bottles){
Robot.moveArmTo(Bottle.x, Bottle.y, Bottle.z + bottle.height/2)
Robot.openArm()
Robot.moveArmTo(Bottle.x, Bottle.y, Bottle.z + Bottle.height/2 Robot.arm.height);
Robot.closeArm(); // uses some pressure sensors to find out when arm is in contact with bottle neck
Robot.moveArmTo(Pond.x, Pond.y, 0-(Bottle.height)); // dip bottle in pond
// how much we wait would have to factor in some physics equations, for example we would need to figure out
water density by weighing it, extract mass, factor in gravitational pull, add some tolerances, factor in Bernoulli to take
air compression into account on initial dip etc., check time taken to overcome bottle buoyancy force, maybe factor in
the time taken to extend the arm into the water and back.
// but lets assume it takes 1 second to take out 1 liter of air out of a 10x10x10cm cube
// Bottle.volume is Math.PI * Bottle.diameter * Bottle.height
// if Bottle.height = Bottle.diameter then it takes (Bottle.volume/1000) second
// if Bottle.height is twice the diameter, it takes 2 seconds
// therefore total time required is Bottle.height / Bottle.diameter * (Bottle.volume/1000)
// but the bottle neck also affects our time
// if Bottle.neckDiameter = Bottle.diameter then it takes what it would take normally
// time reduction is inversely proportional but cannot be less than 1
// so final equation is this
Bottle.volume = Math.PI * Bottle.diameter * Bottle.height;
Var timeToFill = (Bottle.height / Bottle.diameter) * (Bottle.volume/1000);
Var bottleNeck = Bottle.diameter / Bottle.neckDiameter;
If(bottleNeck < 1){
bottleNeck = 1;
}
timeToFill = timeToFill * bottleNeck;
Robot.wait(timeToFill);
Robot.moveArmTo(Bottle.originalX, Bottle.originalY, Bottle.originalZ + bottle.height/2);
Robot.openArm()
Robot.moveArmTo(Bottle.originalX, Bottle.originalY, Bottle.originalZ + bottle.height/2 + Robot.arm.height);
}
Robot.parkArm();
// done.

We run the program above and conclude the bottle gets wet on the outside but doesnt fill with
water. Maybe only a few drops.
Can you figure out why? There are two reasons why in the program above.

Truths
-

Aim to create value using little to no resources


Do not need to know everything in order to create value; only need to know what, how and
where to find, learn, interpret and apply useful information to process data into
information, or useful work
Will always aim to do the least amount of work for the highest amount of achievement
In a perfect world, a software engineer is valued based on his skills in the following areas:
o Cognition
o Reading and Writing Computer Language
o Learning
o Problem Solving
o Reasoning
You may however cheat through with experience, solve problems by customizing pre-made
solutions; but improving your memory through repetition and exercises is what will
ultimately turn you from boy into grown man
An experienced developer indirectly distinguishes himself from an inexperienced one
through behavior. An experienced developer is more disciplined, more straight-to-the
point, more robot-like. An inexperienced developer unfortunately is still very human, and
humans are the worst developers

Comparison

Situation
Approach

Estimates

Prep work

Beginner
- Is either too subjective, or too
objective
- May like or not like the project
based on his limited experience
with other similar projects
- May like or not like the project
based on presumptions about
the people involved in the
project
- Is inconsistent, doesnt know.
- Gets asked when its going to
be ready, gets mood-swingy
because of this; delays
releases; causes failed launches

Gets seduced by colorful tools,


sexy frameworks with catchy
names, wants to use them in
the next project; doesnt know

Engineer
- Is pragmatic
- Doesnt care how interesting the
project is. To him, it is a problem
that can be solved using a
computer through skill
- Knows his team, his customer,
his end-user. Makes
recommendations/assigns tasks
based on this
- Gives both optimistic and
pessimistic estimates, follows-up
after analysis
- Updates regularly, can easily
commit to compromise in the
face of hard deadlines, but does
everything in his power to avoid
compromising
- Utilizes the right tool for the right
job. Is fast with no framework,
faster with time-tested tools,
some likely dating back to the

Starting a
new project

if theyre right or wrong for the


project
- Is driven by autosuggest
wizard tools that dont work as
advertised; tools tend to
somehow stand in his way
- Plans again mid-project,
changes an entire framework,
and the decision is not based
on realistic facts or correct
observations
- Mumbles incoherently when
asked about his decisionmaking process, is flexible in
his rules set
Looks for boilerplate code, finds none,
doesnt know where to put code or
files; has trouble figuring out where
his files are; spends a day

Taking over
a project

Comes into a project, looks file by file,


wastes time, starts grepping for wrong
variable names; his intuition is failing
him

Finding a
bug

Console logs in few wrongs areas,


doesnt know why program behaves
the way it does, tries the debugger,
doesnt understand it, looks for source
maps, doesnt find any. Finally offers
to recode the entire program
Googles for solutions. Tries found
solutions one by one. Doesnt really
know what the code does. Finally puts
in some more code and the problem is
solved, but code is broken in other
areas during the process, and theres
also a major security whole introduced
with a fix.
- Is hard working, tells his friends
how he spent 2 hours on a bug
and strongly believes it makes
him appear a better coder
overall
- Has frustrations / is emotional
- Defers tasks perceived to be
hard
- Cannot really write algorithms,
so googles all over the place for
potential solutions; leaves no
comment behind

Solving a
bug

Writing a
feature

early 90s (vim, Excel).


Has an agenda; bends tools to
follow his agenda
Can easily change an entire
framework, because it is
deliberately decoupled by design.
Doesnt care
Has strict coding rules, can offer
detailed explanations,
arguments; can answer lots of
why question thrown in a rapid
succession

Follows Systematic Development


processes, ideologies, adheres to
Coding Standards, Best Practices,
Development Principles; as a result,
everything is right where you would
guess it would be
Has a general pre-conceived idea on
how the program might work, based on
inference, deductive reasoning,
educated guesses and relevant
observations
Pinpoints the problem through a series
of educated guesses and systematic
code separation; also comes up with a
list of key optimization points. Knows
what hes doing and what the program
is doing.
The bug if not already solved from
above step, goes on a document with
other propositions, gets submitted to
upper management straight away.

Works smart; spends 30 minutes


on planning and analysis, 3
minutes writing
Prioritizes by logical order based
on planning above
Writes fast algorithms easily,
goes for dirty hacks if faster, but
documents them through code
comments
Knows exactly what to apply and
where, and the implications of
doing so

Result

Technical
debt

Profitability

Project destruction.
The product is not entirely
valueless, but hard to develop
on, hard to write features, hard
to maintain
Product is on risk to the
company, can turn from an
asset into a liability in time

Doesnt know what it means


Remembers vaguely seeing
some //@ but doesnt really
know what they refer to since
he never really studied the
code
Requires lots of marketing
Company is wrongfully hiring
more customer support

Requires little to no additional


input to sell the product
Product is of great value, a
pleasure to work on code flows
in naturally
Easy to maintain, easy to add
features
Other companies get interested
in developed product
Is mindful of all the @FIXMEs and
@TODOs in the project
Addresses technical debt as soon
as practical

Product sells itself


Customer support is now selling
training adjacently

Speed
Arguably the biggest mistake beginners do is writing code when they shouldnt. As developers,
we want to spend as little time coding as possible, while achieving the highest amount of return
available. We wind our algorithms around universally true situations, and we handle as many
cases as possible if not all, using code that is inherently reusable.
This is immensely preferred, because we want to avoid:
-

Being distracted while writing code


Losing our train of thought while writing code
Reinventing the wheel
Performing judgement errors
Overhead bug fixing

Obviousness
In a typical problem, an apparent solution may not be obvious. However, nothing stops a dev
from updating a project Readme from time to time if discovers that a better solution better suits
a task at hand.

Example
$1000
BOX A

$0

BOX A

$1000

$1000

$700

Theres two boxes; Box A and Box B.


This game is as follows: you get to pull from either box A or box B. If you pull from Box A a note
with $1000 written on it, I pay you $1000. If you pull one that has $0 I pay you nothing. If you
pull from Box B, the only note you can pull is a note with $700. From which box will you pull?
The next step is we switch roles. You still get to pull from Boxes A and B, but this time you are the
one who is paying out. If you pull from Box A $1000, you pay me $1000. If you pull from Box A
$0, you pay me nothing. And if you pull from Box B, the only option is you pay me $700. Again,
which box will you pull from?
What do you think? Can you write an algorithm that tells you exactly what boxes to pull from
over the course of 100 games?

Das könnte Ihnen auch gefallen