As a Programmer,How I became Rich

The year is 1999. I’m 21 years old with a 3 month old baby and wife to support. I had a job supporting people with disabilities that paid $8.75 an hour and I was in college studying photography. I remember how crazy it seemed that I got a $0.50 raise after 6 months at that job. That was simply not going to work.

When I was younger my Dad who was a programmer had always encouraged me to learn programming but I mostly spend my days on the computer playing games and wasting time. I had been given a ton of opportunity but never made use of it. That was a free education that I threw away.

---

But when you have mouths to feed, your motivation changes. I wanted my little girl to eat only organic food, and I wanted to buy a house for my new family. I knew that working at a dead end job wouldn’t get me there. So I took some money that I had saved up and bought a Power Mac G4 and a huge 21" inch monitory for $1600. It was a huge expense at the time (my tuiton was $3400 for the year). My job required me to work nights so I would drag my huge computer and monitor every night to work while my clients slept.

I had discovered Flash through the work of Yugo Nakamura a digital artist and the first huge interactive design star. I was blown away, this was the first product that let people combine music, type, video and code interactively. ActionScript 1 was basically a joke but it got the job done. The web was still in it’s infancy but the first bubble was well on it’s way.

I spent every night learning from Yugo P, Joshua Davis, Todd Purgason and more. I studied how they did their designs, their code. There was no stack overflow and bugs would drive me mad for nights. But because I could create beautiful visual interactive pieces I was much more motivated than trying to make some boring site. It was all about the story for me. I found what motivated me to learn and kept at it, constantly.

---

During this time I still had to work at my job at night so during the day I barely got to see my baby girl. I would get home at 9 am while she was just waking up and pass out until 6pm. It was excruciating thing to miss and I made a promise to myself that I would double my income in a year. I remember selling my beautiful Fender 1969 Bassman amp to pay the bills and how being poor really fucking sucked.

---

Fast forward 3 months, I had gotten my first web site client and an internship at a web design studio Om Sites that was basically a front for a local pot dealer. The owner was never around so I basically ran the business myself making $10 an hour now. After 3 more months of this I demanded that he hire me full time and I got a raise to $20 a hour. I was basically running a full design agency for local businesses by myself. I had no idea what I was doing business wise but I flailed around and did my best. Some of my work started to get noticed, my work was reviewed by Todd Purgason and my site for the Olympia Film Festival got me nominated for an award.

At a conference in Seattle in the fall of 2000 I ran into a VP of Engineering for a new startup Headsprout and next thing I know, I’m moving up to Seattle with my little family making $40 an hour at the age of 22. In just a little over a year I had completely transformed my life, all through learning to code. Not only did I double my salary, I actually quadrupled it and set myself down the path for future success. $80k a year might not sound like much right now but adjusted for inflation thats $109,776.07.

---

Why does this story matter?

1. You have no excuse for not learning to code. I did it while poor, working another job and supporting a family of 3 at 21. Get off your lazy ass!
2. College and other schools won’t teach you how to work hard. Only actually doing the work EVERY SINGLE DAY will teach you that.
3. While making huge projects might sound like a difficult task, you can break it down it into little experiments. Before I did my first site, I worked on my first button, my first animation, my first video. I took small steps to build up to something greater than the sum of it’s parts.
4. Learning to code is more than about the actual coding, it’s logical thinking and abstraction. That’s a skill that’s just as important as anything else and can be used beyond programming.

Every new startup founder these days does some hand wringing about trying to find a technical co-founder but that is a sorry excuse. With all the tools we have now like Stack OverFlow, Treehouse, Codeacademy, you can build your first Rails, Web, or iPhone app in just a month. One month of work to transform your future career. I bet you it’s taking you longer than that month to go find that magical “tech” guy to help you build your dream.

Even if you don’t want to be a full time coder, learning this skill is valuable in hiring and managing products and people. How the hell do you know what it means when the server is down or the database won’t connect until you actually get your hands dirty? How do you know if you have found a good programmer if you don’t understand the basics?

When people say hustle, what they really mean is do the fucking work.

10 things a programmer must invest in

Investing

Devote (one’s time, effort, or energy) to a particular undertaking with the expectation of a worthwhile result. 0.) Your Health It is a no-brainer that being a software developer is one of the most sedentary jobs out there. Sitting from 8 to 16 hours a day with minimal breaks in between is a sure fire way to build those fats around your belly. Obesity is a risk amplifier for other kinds of sickness and heart attack is the most infamous among them. This can be avoided by allocating time for exercise or if possible, by spending a little extra on a gym membership.
Prolonged typing in an un-ergonomic way also introduces developers to repetitive strain injuries like carpal tunnel syndrome. This can be prevented by stretching your wrists every few hours of typing and by investing on a wrist rest for both the mouse and the keyboard.
Staring at the monitor also puts strain on your eyes that is why it is advisable to invest in anti-glare lenses for your eyeglasses instead of the normal ones (assuming that you are wearing eyeglasses)

1.) Improving Your Math Skills Math skills improve your logical thinking skills, problem solving attitude, and in many cases, your patience. While some math topics can directly be used in software development like discrete math, some can safely be forgotten depending on your field. For example, game developers make intensive use of physics and calculus but I struggle to find its applications in my line of work as an enterprise developer. In any case, math skills will make you a better person.

2.) Improving Your English Skills All popular programming/scripting/markup languages use English and comments in open source projects like Linux are also in English. Developers around the world collaborate using the English language. Developers who work for international clients are forced to know English for them to be able to translate the business needs into a solution.
Get the point? English is to humans as binary is to computers.

3.) A Personal Domain + Website Don’t you find it cool to have your own email address as compared to having a generic one like something@yahoo.com orsomeone@gmail.com? Having your own domain name helps you stand out among others at a very small annual fee. I bought my lambdageek domain for a measly fee of 13 USD. A personal domain also gives potential clients/colleagues an immediate sense of confidence and professionalism in your brand which is you – your self. This is assuming that your domain name is not hotmale-loves-chicks.com

4.) An Active Github Account Portfolio is to artist as Github is to developer. Nuffsaid.

5.) A Go-to Machine Did you hear about the developer without his own machine? Me neither. Being a software developer without having your own dev machine is like being a Jedi without his lightsabre. A good go-to machine as of this writing should have at least 4 GB of RAM (8GB to make it future-proof). I could simply recommend the 4000 USD Mac Pro but I reserve that for those exceptional cases with extreme needs.

6.) Fast Internet Connection Internet is the oxygen of programmers. Being off the grid for a prolonged period of time is just like cutting my air supply and is simply unbearable. Having a stable connection gives you the privilege of learning from video tutorials, participating in forums, and even getting up to date with the latest articles in Hacker News.

7.) Reading Classic Computer Science Books Some texts which I deem to be the scriptures of software development are:

• Structures and Interpretations of Computer Programs
• Code Complete 2
• Pragmatic Programmer
• Refactoring
• Introduction to Algorithms (The MIT Press)
• Discrete Mathematics and Its Applications
• Mythical Man Month

8.) Bachelor’s Degree A Bachelor’s Degree would greatly increase the odds of someone landing a job. This applies whether you are a fresh graduate or someone who just left his job and is looking for a new one. Just imagine the fact that: If millions of graduates fight tooth and nail against each other just to get hired, then how much harder would it be for an undergraduate’s resume to not land in the ignore pile?

9.) Certifications (optional) Certifications test an applicant’s skill in a particular technology. Passing a certification means that a person is “certified” to have a deep understanding of something which might be of value to an organization. Some companies put a premium on certified developers by giving higher salaries while other companies don’t care about certifications at all (and for good reasons). For example, being a Certified Java Programmer means that you know the Java language in and out however, this does not directly translate to your ability to solve problems. Some companies value someone’s critical thinking skills over his/her expertise in a programming language since programming languages can easily be taught and learned but problem solving is not.

As programmers why we never finish our projects

Every developer starts about 100 projects that never end up going anywhere. So many good ideas, so few executed ideas. Just about every software developer that I know has a folder structure that resembles the one shown. More than a handful of incomplete projects that seemed like a great idea once upon a time. Like many of you, I’ve had many ideas for great products / companies and even started down the path of implementation for some of them. A bot that determines arbitrage opportunities between eBay and Amazon. A social network for referral based businesses (plumbers, electricians, software developers, etc). A bitcoin search engine. A CSS framework for the days when Bootstrap wasn’t literally everywhere. A “hot or not” that found people from Instagram. A real-time visitor analytics engine. The list goes on. I’ve started on just about every one of these projects (and more), but never saw them through to completion. In talking with my developer friends and colleagues, I find that the story is oft repeated. Some folder on their computer that lives as a graveyard to high hopes and incomplete dreams. I’ve wondered why this is.

Success as an Obstacle

We, as an occupation, are blessed with high employability. Currently, the national unemployment rate is around 6.7%, while the unemployment rate for web developers is closer to 1%. Our salaries are also substantially higher than the average. In 2012, the median income for software developers was more than $90,000, now of course, if you’re any good, you can far exceed that. Having taught complete n00bs before and watching them become entry-level developers has brought me a great deal of personal satisfaction. But it’s also brought them financial satisfaction, with starting salaries ranging from $45,000 to $70,000.
So it’s clear that software developers are generally successful. Yes, there are thousands that completely suck. There are many that are not paid well at all and can’t hold a job for very long. But I’m making a generalization here, so allow me the liberty to be general. A halfway decent developer is a relatively (compared to the general population) successful person. This success can paralyze and inhibit the completion of goals, however. We are far from hungry and we’re too smart to think that we can ever be foolish.

The impediment of Knowledge

We know so much. We can talk about the shortest way to travel between multiple cities. We understand how to take large problems and break them into smaller sub problems. We can tell you the best way to “abstract” whatever your system is into discrete units. We are true polyglots as we can say “Hello World,” in any number of languages. We don’t shy away from situations that might require thousands of calculations since we understand the power of recursion. We know a lot, but is that enough? The great Einstein once quipped:

A little knowledge is a dangerous thing. So is a lot.

Sir Isaac Newton, one of the smartest men of his time, could accurately predict the movement of celestial bodies so many millions of miles away. He stood on the shoulders of giants to see farther than anyone else had. Physics wasn’t his only interest as he also (co)gave us calculus. Surely he could understand how money and markets work, right?

Wrong. During 1720, at the peak of the South Sea Stock Bubble, he threwdown a ton of cash and went broke. All of his knowledge didn’t help him one bit, because he failed to understand the dynamics of markets. His knowledge was not domain independent — he was a master of moving bodies, but that did not translate to the psychology of his fellow traders. We too are like that. While we can explain algorithms and data structures all day long, we may not inherently understand what people want. When the twitters first came about, I suspected it was just a fad that would disappear. I was wrong. We often seek sexy solutions without realizing the mundaneness of the problem.

Career ADHD

I’m sure the same holds true for any major city, but I am speaking of my experience and the experiences of my colleagues and friends in the New York City area. We jump around in our careers. We swing between startup, corporate, agency and “just taking time off.” I realize this doesn’t hold true for everyone, and the trolls of the internet will leave comments with how they’ve stayed at the same job for 19 years, but I have found that those with the passion / interest in having a side project, often don’t stay at one place for too long. I think that this Career ADHD leads to many abandoned side projects.
Sometimes a new job starts up and the demands of getting caught up there mean putting the side project on “pause.” Sometimes we lose interest because the side project was aligned with something that we were doing at our previous job. While logistics is a reason that switching jobs every few years makes it much harder to stick to a side project, there is something to be said about the mentality of switching. If you can change your job in 3 years, why not change your side project in 3 months? You’ll have a better idea at (seemingly) the exact moment that you hit a wall in your current side project.

Fixing It

So I’ve identified a few reasons that I think that I have so many unfinished “great ideas.” Admitting it is the first step. Understanding the reasons why is the second step. Now, for the third step — fixing it. It won’t be an overnight solution and many of my projects will remain forever abandoned, but after thinking through it a bit more, I think I’ve come up with some steps to help this from becoming a pattern.

You are Awesome

First, recognize that every side project makes you a slightly — or in some cases, substantially — better developer. Your skills are the sum of the times they’ve been applied, so the more you develop, the better you become. Learning new technologies / languages / frameworks is a great reason to start a side project. Even if it never finishes, something was accomplished. So, first realize that you don’t always have to finish every project — as long as you walk away with some gain.

Build parts of Projects

You’ve started so many projects and, as you got wiser with each, hopefully you learned to reuse code. Building modules and libraries instead of rewriting everything each time. Assume that whatever side project you’re working on now may not be the last one, so you’re better off grabbing components from it instead of of building specific things that ONLY this project can use. Documentation matters, so leave notes for yourself that can be easily applied to the next project.

Do it with Others

Now that we’ve gone through successful ways to fail completing a project, let’s try to complete some! It may be your brilliant idea, your baby, your future billion dollar empire, but as of right now — it’s nothing. Share it with other people, the more the merrier. The natural excitement will continue to propel the project forward. Maybe you can even open source it, to encourage community participation? Relying on others and having them rely on you keeps you foused and accountable.

Solve problems you Have

Rather than making your next project an iPhone app that lets you take pictures of food while you travel by bicycle in cities that have cloud cover 43% of the time where the nightlife consists of urban zoos that hold endangered genders of overpopulated species — try to make something that you would ACTUALLY use. If you’re a developer, solve developer problems. If you work for an agency, create something that agencies would like to use (see: 37 signals). Even in your personal life, you invariably have some small problem that technology can solve, so why not create something to solve it? That way, even if it doesn’t actually go anywhere big, at least you built something useful.

Size matters, so stay Small

Don’t create an enterprise XYZ when the timeframe to do so would be 8 months. Focus on something you can create in 4 weeks, part time. Scale your features back to keep a monthly release cycle, no matter how simple. Having something shipped has a strong psychological component that further encourages you to work on it. Something sitting on your laptop for 8 months that has never seen the light of day is almost depressing to work on. It’s all about the little wins, since the journey is a marathon instead of a sprint.

Brag until you Fail

Social pressure is a real thing. It’s why skinny jeans became a thing. Instead of working in secret, tell people what you’re working on. The feedback you get might help shape the product. I can assure you, no one is out to steal your idea. It’s extremely hard to execute even a simple idea, so don’t worry too much about that aspect. Share your idea, it’ll validate (or invalidate it), shape it and most importantly, commit you to it. We don’t want to let people down and we do want to save face, so tell people what you’re working on.

What about you? What tips and tricks do you have for getting your projects done?

Which Type of IT Career is Best For You?

nsidering the growth of the information technology job market, a career in IT is an incredibly smart career move. A career in IT can mean many things – you can become a network administration, website developer, database specialist, programmer or engineer.


The job range is vast and can suit various personalities and levels of technical skill. Having a good insight into those job profiles is key to make the right decision about your career path. Here's a selection of some of the most interesting and profitable IT careers and skills they require to make it in the field.


Software Engineer


Software engineers are the guys behind all our programs and games. Whether it’s personal computers or mobile devices, software engineering is an area with many sub-divisions. If you've got a knack for design, you can channel you creativity and combine it with the knowledge of a programming language like Java to create captivating games. Education? A bachelor degree in software engineering is enough – it's all about your experience, past projects and college credentials.


Web Developer


Just like software engineering, web development spans over many areas, such as web applications, web pages and web content. The skills involved in this field are greatly varied. Nowadays, web developers need to consider things like user experience, have a firm grasp on the workings of an operating system, know how to entice users to click on their products and have an idea about site optimization for mobile. Web devs are usually proficient in web languages like Javascript or HTML. What credentials will you need to make it as a web dev? Many of them get their jobs through their portfolios, but accredited degree programs probably offer an easier starting point.


Cloud Architect


Cloud architects are responsible for giving a shape and order to the storage space that exists in the cloud. This is a rising sector with a lot of demand for applicants, which eventually receive one of the biggest pay checks in the IT department. A necessary starting point is a bachelor's degree in the area.



Mobile Application Developer



With basic coding languages, mobile app developers can build applications for Android or iOS devices. Mobile apps are now cutting edge and are expected to be more popular than PCs in near future. What does it mean? More businesses than ever will rely on professionals with this kind of experience. To enter the field, you'll need a bachelor's degree in computer science, software engineering, or other.



Data Specialist



Every day, we produce gigabytes and terabytes of data that companies need to store in order to make sense of and predict consumer behaviour. Data analysis isn't limited to commercial use and the sector is rapidly growing – just like our reliance on computers to manage all our information. A data specialist will know how to model data, create data designs and define relationships between data fields. A bachelor's degree in computer science, IT or mathematics plus some professional experience will do the trick.


Kelly Smith is a dedicated tutor and writer. Currently, she develops her passion at Career FAQs, one of the leading providers of career and educational resources in Australia, where she provides career advice for students and job seekers.

As A Programmer, Do You Really Like Your Job?

I love how things happen. First, I ask for feedback on the blog Facebook page about what types of posts people would like to see. Someone asks for more career advice for senior level people, and then two other blog posts appear that make my job a lot easier. There are a lot of topics to talk about when you look at career advice for seasoned veterans of industry. Today, I wanted to focus on making sure you, as a software engineer, were doing the right thing for you. Basically, software engineering is difficult work and typically high stress. So, if you don’t really like your job, you need to do the right thing and find one that you can like or even love. The real question is how do you know it is time for a change?

Erik Petterson has a really interesting post where he compares job satisfaction to a coffee table. It is a very good post that gives you a nice overview of how to check if you still like your job:

My advice to those disenfranchised with their jobs.  Inventory their job satisfaction coffee table.   Ask yourself, “Am I getting paid reasonably? Do I like what I’m doing, who I’m doing it with, and whether the good times seem like they’re gonna continue or not?”

There are plenty of websites where you can check the average compensation for a software engineer in your geographic location. So, you should make sure you are at least near the average or above it.

The team that you work with is also very important, because they can make a job much more enjoyable. I have had some jobs where I had no interest in going to happy hour after work with a large group of coworkers. On the other hand, I have had teams where the people are almost like family and working with them became enjoyable even if it was stressful. Ask yourself, do you really like the people that you work with? You spend at least 40 hours per week with them, and probably another 10 hours per week thinking about them when you are home. Not liking them will just make your home life more difficult.

Job stability is a bit of a misnomer in our current industry. Even the giants like IBM, Microsoft and even Google have laid off people in the past two years. If you work for a smaller company, stability is always a question. The problem is that you have bills to pay, so a steady paycheck is required. What you want to do is figure out if the company itself is somewhat stable. Have they had a lot of people leave for other jobs in the area? Does the company have an increasing customer base? Are they cutting little perks like free coffee or bottled water? Also, how happy are the employees on average? All of these point to the general health of the company, and can tell you whether you should be looking for a new job in order to protect your financial well-being.

Lastly, and probably most important for software engineering is, do you really like what you are doing? For some people, love of their work can override any deficiencies in the other areas. That is not always a good thing, unless you are already wealthy and the paycheck does not matter to you. At some companies, the work will always be really interesting and a lot of fun to work on. However, there are not a lot of those types of jobs, but there are plenty that you can like. How do you know if you do not like your current job? Merlin Mann wrote a fantastic post about cranking. His descriptions of cranking are probably all too familiar to some of you:

I didn’t have time to think about my family. Not now, right? No, I had to keep working… So, I’d type and type. I’d crank and crank. I’d try and try… I would do my job until I hadn’t the slightest idea what time it was or what bullshit I was typing or what my crank was ever meant to be attached to in the first place. But, even when my shitty little crank was not attached to anything, I did keep cranking. Because, Dads do their job. It’s what they do. They crank. They crank and crank and crank and crank.

Have you ever been in that type of position? No matter how much work you do, you have that much more to do. If the work is not interesting, then it really is just like turning a crank on a bed. Eventually, you go to work, do whatever is needed and collect a paycheck. There is no joy in this life, and enjoying your job is very important to your overall happiness. If you have found that you dread going to work, without even knowing if there are problems, then you are probably just cranking. Merlin has an excellent quote in that same post on what you need to do:

It’s now become unavoidably clear to me that I’ve been doing each of these things poorly. The job, the making, the pleasing, and, yeah, the being at home. And I can’t live with that for another day. So, I’ve chosen which one has to go.

You have to remember that you can change a lot of things. You can change how you do your job, and maybe make your company a better place to work. If that is not possible, what else can you change? Maybe it is time for you to change your job, unless you really like that crank.

Want to write some code? Get away from your computer!

I’ve recently realised something. The best place to write code isn’t in front of your computer, with your compiler, IDE and tools. The best place to write code is far, far away from any of these tools – somewhere where you can think properly. For a language with which you are fairly familiar, the mechanics of translating the program in your mind to a program that the compiler can compile (or the interpreter can interpret) is fairly easy – it’s coming up with that program in your mind which is hard.

The other day I was on a train journey. I had my laptop, but no internet. Unfortunately I was using a commercial programming language (IDL, as it happens) for which I need to use my university’s site license. As I didn’t have access to the internet, I couldn’t get hold of the site license, so couldn’t run the compiler and IDE. Say what you like about commercial programming languages which require expensive licenses, but it stopped me from actually writing code in my editor with the compiler. And…guess what…it actually made me think!

I guess this post is somewhat along the lines of Does Visual Studio rot the mind? and the following quote:

One of the best lessons I learnt from my first boss was: “when your code doesn’t behave as expected, don’t use the debugger, think.”

That is what being away from your compiler forces you to do. It’s very easy to slip into the mindset of:

Write a bit of (fairly bad) code
Compile and run
Test with a poorly chosen test case
Find it doesn’t work
Make small change to the code on the off-chance that it might solve the problem
Repeat…
Of course this leads to code in the end that is ill-understood by the programmer, probably fairly buggy and not well tested.

Being away from the computer forces you to run through all of the thoughts in your head – which tends to take longer than getting a computer to compile and run your code (for small code bases at least…). So you don’t tend to make tiny changes and re-run things, you tend to actually think about what the code is doing. Until I did this on the train the other day, I hadn’t actually run a piece of code on paper (that is, written down columns for each of the variables and worked out what each value will be at each stage in the program) since my Computing A-Level exam!

In the case of the code I was writing the other day, I managed to produce some high quality, fast, bug-free code by writing it in long-hand on a piece of paper, thinking about it, gradually typing up bits of it, thinking some more, and then after a long time trying it in the compiler. The code (which was some region-growing image segmentation code which involved lots of recursion) was eventually copied from my piece of paper to my IDE, compiled (with only one syntax error – impressive I think) and ran correctly first time (and completed all of the tests that I had also devised on paper).

Job well done, I think, and a useful piece of advice, I hope.

malloc/free and new/delete in C++

malloc and free are C++/C language standard library functions, while new/delete are operator of C++. They can be used to allocate dynamic memory and free memory in C++ programs 

malloc/free can not meet the requirements of dynamic objects creation. Object needs to call the constructor to initialize the object when creating, the object needs to call the destructor before it is destroyed  Since malloc() and free() are library functions rather than operators, the compiler has no control permissions on them, so it can not impose the task of object construction and destruction on malloc() and free().

Therefore, C++ has an operator new to complete object dynamic memory allocation and object initialization, and an operator delete to clean up the object and release the memory allocated to the object. Note that the new/delete are not library functions.

Let's take a look at some codes to understand how malloc/free and new/delete to do object memory management.

class Obj 

{     

  public : 

          Obj(void){ cout << “Initialization” << endl; } 

          ~Obj(void){ cout << “Destroy” << endl; } 

          void    Initialize(void){ cout << “Initialization” << endl; }  

          void    Destroy(void){ cout << “Destroy” << endl; } 

  }; 

     

  void UseMallocFree(void)

  { 

      Obj  *a = (obj *)malloc(sizeof(obj));   // allocate memory

      a->Initialize();                                     // initialize

    

      //… 

    

      a->Destroy();   // clean up

      free(a);        // free allocated memory

  } 

     

  void UseNewDelete(void)  

  { 

    

      Obj  *a = new Obj;  // allocate memory and initialize

    

      //… 

    

      delete a;                   // clean up and free allocated memory

  }

Initialize() function in class Obj simulates the function of the constructor and Destroy() simulates the function of the destructor. In function UseMallocFree(). since malloc() and free() only take care of allocating and freeing memory, we need to call Initialize() and Destroy() to initialize the object and destroy the object. It's much simpler if we use UseNewDelete().

Since new/delete have all the functions of malloc/free, then why doesn't C++ rule out new/delete? This is because C++ programs need to call C functions frequently and C programs can only use malloc/free to manage dynamic objects.

If using free() to free the object created using new, then this object will produce error because it cannot call the destructor to destroy the object. If using delete to free the memory allocated with malloc(), theoretically the program will have no problem, but the readability is very poor. So we recommend to use new/delete as a pair and malloc/free as a pair as well.

Computer skills one can learn within one day

Computer related technical skills are usually thought as complicated and difficult to understand. It's very difficult for one to get hands on one skill or master one skill. But if you really do want to learn something useful within one day, there are some good choices which will not take too long to get to know and use..

• Version control:- Git, GitHub and SVN
• Regular expressions
• AWK
• sed
• Grep
• Learn how to do things with Vim that you never knew could be done.
• Set up a crawler that can scrape some webpages and parse some basic data.
• Set up a bigger crawler that has to fill out a form or two.
• Program a basic linear algebra library (matrices, vectors, multiplication)
• Add least squares regression to this library.
• Make your library work efficiently with sparse data.
• Learn how to use list comprehensions in Python.
• Get a Stack Overflow account and learn to use the site.
• Read the freaking manual for your favorite language.
• Implement a simple machine learning algorithm on your own, with a whole pipeline.
• Learn the how to make a simple line graph in Excel.
• Get your eclipse installation fully pumped up.
• Learn the basic functionality of a NoSQL database.
• Learn the most basic functionality of SQL
• Understand difference between SQL and NoSQL databases (strengths, weakness, limitations, where to use which and why etc.)
• Getting comfortable with Linux. 
• One or two sorting algorithms. (Perhaps Quicksort and Mergesort)
• Learn how to effectively develop unit tests for your code.
• Familiarize yourself with some of the AWS services and their API in the language of your choice
• One algorithm a day
• Understand need for distributed processing and distributed data storage and challenges in them (basics of CAP Theorem, MapReduce algorythm, clustered MySQL or PostgreSQL database)
• Learn how to edit Wikipedia articles both syntactically and under wikimedia guidelines, such as neutral point of view.
• Learn how to write in markdown
• LaTeX, BibTex, and pgfplots
• Learn how to work from the command line
• Learn JavaScript
• If familiar with OOP, learn design patterns.

Ok, why not go and have a try?

Female friendly programming languages

Women are minorities among programmers. It seems programming languages are created for males, either. They are full of maths and weird jargon. Are there programming languages which are female friendly? What kind of programming languages can be considered as female friendly? Gayle Laakmann McDowel shared her views on which are female friendly programming languages.

Women are 87.3% more likely to prefer languages like Ruby and Perl, because they remind us of shiny objects. All women love shiny objects.Smalltalk is another favorite language. Women love to gossip.

Languages like C++ and C# are scary though, because you've put, like, math in the language name. Eww. Gross.

Python is also a no-no because, I mean, you just named a language after a snake. Ick! And, I mean, do I need to call out the Freudian imagery there?

Java and OCaml are a toss-up. Unlike women's universal love of shiny objects and gossip and their universal fear of reptiles and math, only some women like coffee and desert animals.

Serious Note: Programming languages are not "female friendly" or "male friendly." They are not gendered. There are no attributes of programming languages that make them better for one gender.

The 5 types of programmers

In my code journeys and programming adventures I’ve encountered many strange foes, and even stranger allies. I’ve identified at least five different kinds of code warriors, some make for wonderful comrades in arms, while others seem to foil my every plan.

However they all have their place in the pantheon of software development. Without a healthy mix of these different programming styles you’ll probably find your projects either take too long to complete, are not stable enough or are too perfect for humans to look upon.

The duct tape programmer

The code may not be pretty, but damnit, it works!

This guy is the foundation of your company. When something goes wrong he will fix it fast and in a way that won’t break again. Of course he doesn’t care about how it looks, ease of use, or any of those other trivial concerns, but he will make it happen, without a bunch of talk or time-wasting nonsense. The best way to use this person is to point at a problem and walk away.

The OCD perfectionist programmer

You want to do what to my code?

This guy doesn’t care about your deadlines or budgets, those are insignificant when compared to the art form that is programming. When you do finally receive the finished product you will have no option but submit to the stunning glory and radiant beauty of perfectly formatted, no, perfectly beautiful code, that is so efficient that anything you would want to do to it would do nothing but defame a masterpiece. He is the only one qualified to work on his code.

The anti-programming programmer

I’m a programmer, damnit. I don’t write code.

His world has one simple truth; writing code is bad. If you have to write something then you’re doing it wrong. Someone else has already done the work so just use their code. He will tell you how much faster this development practice is, even though he takes as long or longer than the other programmers. But when you get the project it will only be 20 lines of actual code and will be very easy to read. It may not be very fast, efficient, or forward-compatible, but it will be done with the least effort required.

The half-assed programmer

What do you want? It works doesn’t it?

The guy who couldn’t care less about quality, that’s someone elses job. He accomplishes the tasks that he’s asked to do, quickly. You may not like his work, the other programmers hate it, but management and the clients love it. As much pain as he will cause you in the future, he is single-handedly keeping your deadlines so you can’t scoff at it (no matter how much you want to).

The theoretical programmer

Well, that’s a possibility, but in practice this might be a better alternative.

This guy is more interested the options than what should be done. He will spend 80% of his time staring blankly at his computer thinking up ways to accomplish a task, 15% of his time complaining about unreasonable deadlines, 4% of his time refining the options, and 1% of his time writing code. When you receive the final work it will always be accompanied by the phrase “if I had more time I could have done this the right way”.

Where do you fit?

Personally, I’d have to classify myself as the perfectionist. So, which type of programmer are you? Or perhaps you know another programming archetype that is missing from my list? Post a comment below and I’ll add it to a new updated list.