Tagged: open source

Hiring Indicators, OSS, and the Value of GitHub

As someone who writes about tech hiring and who has also encouraged many to participate in open source and establish a GitHub presence, a recent article caught my eye. Why GitHub is Not Your CV ¹ by James Coglan was partly inspired by another article, The Ethics of Unpaid Labor and the OSS Community by Ashe Dryden. Both articles are well-written and if you evaluate programmers for hire please read them.

Dryden’s tl;dr for me was meritocracy in OSS, an explanation regarding the lack of diversity, and ways to hire that are ‘less biased‘ than relying on OSS contribution or public code availability. Coglan references her piece and adds his own thoughts around similar topics, but his readers might disregard the value a GitHub presence provides. Neither article tried to discourage a presence, but the Coglan piece dismissed the value quite a bit.
Continue reading →

Hello World! What Every CS Student Should Know About the First Job

Anyone involved with hiring entry-level technology professionals (or reads posts on Reddit’s cscareerquestions forum) is aware that students are being prepared by schools for how to do work in the industry, but are often ill-prepared on how to find work in the industry.  There is a major difference between the two, and many grads are being edged out on jobs by equally or even less-qualified peers who were just a bit more proactive about their career. If you think finding a job is only about internships and GPAs, please keep reading.

Some students feel that if they aren’t working 10 hours a day building the next Twitter from their dorm room, or if they didn’t intern at Google or Amazon, that they will struggle to find work. This is hardly the case, and I assure you that if you do a few things during your college years (that require a minimal time investment and no money), you will be several steps ahead when it is time to apply for your first job.
Continue reading →

The Engineer’s Engineer

Lately I’ve seen quite a few requests for advice from younger programmers, asking questions either directly to me or in public forums about a career decision they are being faced with that is causing some level of stress.  Reddit’s r/cscareerquestions is a hotbed for this type of activity, and you might see the occasional similar post on Hacker News.  After 15 years in business, I’m quite comfortabel providing insight on the potential benefits and drawbacks of say, taking a job doing mostly Python versus a position exclusively using a rarely seen proprietary language and platform, or accepting a pure technical management position versus staying more hands-on.

Generally, I want to tell all these people the same thing.  If you really enjoy the work and want to be successful in the business for a long time, you should try to make decisions, think like, and become an engineer’s engineer.

I know quite a few people I’d describe as an engineer’s engineer, and most of them have some gray hairs or are young but sound like a throwback to times past.  Fortunately, some less experienced developers are benefitting from being able to work alongside someone in this category, who are more often that not open to mentoring and showing the way.  As a recruiter I look at and treat these engineers like gold, as they are the types that any of my clients would want to hire – plus they tend to teach me new stuff in every conversation.

Who is the engineer’s engineer?

  • Utility player –  In baseball, it wasn’t uncommon in the early years for players to play several positions.  Specialization has happened in baseball to the point where there are now pitchers who only pitch in the 9th inning.  Similarly, software development shops are now often filled with segmented roles for build engineers, dev ops, QA, architects, performance engineers, database developers, etc.  The engineer’s engineer is a utility player that can jump in almost anywhere, and doesn’t see the demarcation as a boundary that cannot be crossed.  Little is considered beyond the scope, and they will not want to silo themselves into a singular function.  
  • Initiative – If they see something that is broken, they fix it.  Will automating a task make our lives easier?  If so, let’s do it, and only ask permission when absolutely necessary.  This requires some level of autonomy.
  • Technical integrity – By this I mean that an engineer’s engineer will have some opinions about decisions being made (if this person isn’t calling the shots) and will make that opinion known when there is disagreement.  Instead of just saying an idea is bad, an alternate solution will be given.  This is the desire to do things correctly over taking short cuts, which is likely to conflict with the business at times.
  • Can’t be bought with money or title – This group will never take a job purely based on salary or rate, and are driven by the ability to solve interesting problems and work with a strong team.  Job title means absolutely nothing.  In my experience, most engineers factor money heavily in job decisions and sacrifice a better career move or additional job satisfaction for what amounts to a difference of $2.00 an hour.  If you’ve chosen a job based on a 5K salary difference, this is you.
  • Sharing – The engineer’s engineer wants to share, whether it be information on how and why they arrived at a particular solution, their favorite tools, or anecdotes about past projects.  This is based on a combination of pride in their work and interest in teaching others.  Open source is often a part of this equation, where there is a desire to share your solution for the outside world to see and use.
  • No limitations – The engineer’s engineer doesn’t want to have the toolset options defined and thrives in an environment where they have autonomy over what will be on their machine.  Having a company mandated IDE or OS will be a turn-off, as will any roadmap listing few acceptable tech options.  Heavy bureaucracy, regulation, or barriers to being able to solve problems are an issue.  The shop ideally will be engineering-friendly.
  • No personality conflict, less ego – Of course, many strong programmers (and some weak ones) have quite a bit of ego about what they do.  The engineer’s engineer does not come across as overly self-important, and can be more humble than those much less-skilled.  This group isn’t alway the most friendly or popular person on the team, but is never the most hated.
  • Lack of zealotry – Even though they want to use the best tools, they understand that their weapon of choice might not be appropriate in all situations.  This group knows there are no silver bullets, and laugh when others get overly religious about the new hotness.  Technology and new products excite them, but they are unlikely to get a tattoo of the latest JavaScript library.
  • Movement – This group wants things to be progressively moving forward with few delays.  Low latency in their process and little downtime at work.
  • Has the back of team members – Solidarity among other engineers is their goal, and they tend to stay above or away from the drama of interoffice politics.  They are there to solve technical problems, and have no interest in gossip or attacks on others.
  • Know that they are not their code – These people can separate a technical criticism from a personal attack.
  • Doesn’t need to be a leader – They are often more happy when they are not in charge, and are not instinctively driven to tell others what to do.

Note:  In thinking about and doing some mid-article research for this piece, I came across Paul Graham’s 2004 piece Great Hackers which identifies some of the same traits listed here as being shared with hackers.  The hackers he describes should share the workplace desires and drive as the engineer’s engineer, but may not always have the same personality or behavioral traits.

If you found this post useful, you may find my ebook Job Tips For GEEKS: The Job Search even more helpful.  You can follow Job Tips For Geeks on Facebook, Twitter, or Google+.

Indicators of Talent (and Heuristics) for Software Engineers

A recent Hacker News post by a man named Andrew was voted to the front page and received over 50 comments (as of my post).  The post was called Ask HN:  Would you hire me?, and Andrew specified that he was talking about a junior level position.

He provided the following details about himself:

  • 28 years old with a Finance Degree from a non-Ivy league school
  • Spent the last two years living overseas teaching English and learning to code
  • Fairly well versed in html, css, javascript, and PHP

He also included links to his:

  • GitHub – handful of repos, 7 months as a member, pretty active over the last quarter
  • Stack Overflow profile – 521 reputation, top 37% this quarter, 16 badges
  • Blog – Attractive UI, 7 overall posts (a few with some code), with the highlight being details of a Chrome extension he built and demonstrates in a video

Andrew received a fair amount of positive feedback, and not one single poster gave a ‘you are not hirable‘ response.  No CS degree, no professional experience, yet a highly technical audience were either mostly positive and at worst neutral on hiring (considering is more accurate) this potential applicant.  Only a couple responders mentioned looking at the one project he listed, and none referenced the quality of his code samples on his blog or GitHub, so we might assume that no one even bothered to look at his code.  Interesting.

Part of the explanation for the positive response is undoubtedly the makeup of the Hacker News crowd, which does not include a large contingent of HR reps from large companies who control a great deal of the hiring decisions.  Place this resume and story on Monster or Dice, and I expect that Andrew would receive responses from less than a quarter of his viewers.  Possibly less than a tenth.

I admit, if I were to see this candidate’s resume (assuming it reflected the details he put on HN), I would absolutely want to speak to him.  The clients I represent, which are mostly startup and early stage software companies, are more representative of the HN crowd (at least in terms of evaluating engineers) than most larger companies.  And even if I did not have a great opportunity for him today, I would think that a few years down the road he will be someone that I’d want to represent.

What is it about this candidate with no experience and no highly relevant education that gets our attention?  Of the details we have about Andrew, how many could have impacted my decision to speak to him?

When evaluating talent and the decision whether or not to interview a candidate for a software job, I must rely on several attributes that have historically been attached to quality talent that were successful in receiving job offers from my clients.

Let’s break it down.

28 years old with a Finance Degree from a non-Ivy league school – Most readers, including myself, probably didn’t give this any thought.  His degree in finance should indicate some math background, and if he had listed his specific school that would have had an impact.  Although most might be reluctant to mention it, the age demographic is probably a positive based on the industry, as he obviously has some life experience and maturity but will not fall prey to any old dog/new tricks bias.

Spent the last two years living overseas teaching English and learning to code – Teaching any subject to any students is valuable experience for almost any profession, and should indicate some level of communication skills.  The international aspect adds a bit more interesting background than if he were teaching domestically.  Some who chose to speak to Andrew may have been strongly influenced by the oversas aspect, as this could also show some willingness to face risk and change.

Fairly well versed in html, css, javascript, and PHP.  Just getting started with Ruby – His claim of being ‘well versed’ is only a self-assessment, but that could be at least somewhat validated (or invalidated) by anyone taking a look at his blog’s source or GitHub account.  This at least indicates that he is learning technologies that will give him some marketability based on demand for these skills.  We may question Andrew’s choices if he were learning a less popular skill.

GitHub, Stack Overflow, and Blog – For those that make decisions about technical talent, the fact that Andrew has both a GitHub and Stack Overflow account is probably more of an indicator of possible talent than what is actually in the accounts.  Most candidates in my experience don’t have a GitHub/Bitbucket or SO account, but those who do have accounts are historically more successful with my clients than those who don’t.  The attractive blog and few technical posts are yet another indicator, showing some passion as well as the ability to articulate his ideas in writing.

What other details may have led to the decision of HN readers or people like me who would at least want to speak to Andrew?

He reads Hacker News – Even if he isn’t a senior developer, he at least appears to have spent some time in one community where they frequent.

He comes across as modest and doesn’t appear to feel entitled – You don’t see anywhere in Andrew’s post a reference to how awesome he is or how he is ‘kicking CSS’s ass on a daily basis’.  His responses to feedback are very positive, grateful, and polite.  The choice of ‘well versed’ over some other terms that may be linked to overconfidence was wise.  Andrew also will not be accused of sounding entitled to a great dev job, and on the contrary he comes across as someone who knows he has to earn it.  Perhaps that is a function of his lack of a CS degree, but either way he appears to be taking the right approach.

He’s already creating product – Although he is only early on in his tech studies, Andrew has a product on the market that you can find in the Chrome Web Store that you can download.  There are developers with 20 years of experience that haven’t built any of their own tools or products yet, but this guy is two years in and has that mindset.  Some may question how great (or even good) a product someone at this level of experience could build, but the desire to produce and distribute a tool is something that perhaps can’t be taught.

Note:  Other indicators I use regularly include:

  • Past employers – Some companies frankly have a higher standard of hiring
  • Technical hobbies – Arduino, build robots, or create things at home
  • Speaking or writing – Presentations and publications are usually strong indicators
  • Tool choice – What blogging platform or operating system you run at home
  • User group and meetup – Shows interest and passion

Conclusion:  Hiring managers and recruiters are making quick decisions to interview and consider candidates, and as demonstrated by this HN post it seems that there are several recognized indicators of possible talent.  For job seekers, you may want to display links to your accounts prominently, and highlight details such as independent product development.

Of course, these indicators are not perfect.  I, too, have a GitHub and Stack Overflow account and a blog that covers technology (and I even run one of the best Java Users’ Groups in the world) – but I don’t write code.  Readers of HN should not hire me.

Discuss here or on Hacker News.

If you found this post useful, you may find my ebook Job Tips For GEEKS: The Job Search even more helpful.  You can also follow Job Tips For Geeks on Facebook, Twitter, or Google+.

How Hackers Choose Tools (thoughts on Paul Graham’s Java’s Cover)

Recently, a 2001 blog post with the title Java’s Cover written by Paul Graham (of Y Combinator fame) spread across Twitter and was linked by all the other usual tech site suspects.  The piece was about what Graham called ‘hacker’s radar‘, which he describes as the ability of hackers to ‘develop a nose for good (and bad) technology‘.  For his description of hacker’s radar, he decided to cite Java as an example of a technology that smelled bad at the time.  Java’s popularity in 2001 made it a pretty big target for critique.  The title Java’s Cover is a reference to judging a book by the cover, and Graham argued that Java’s cover was a stinker.

Graham admits in the article that he had never written Java and his main exposure was when he ‘glanced over reference books‘, though Graham does have substantial tech credibility as a hacker.  He lists 12 reasons why he didn’t like the look of Java, and mentions that he had a hunch that Java would not be a very ‘successful language‘ (but he ‘may turn out to be mistaken‘).

The commentary on the aforementioned usual suspect sites seems, predictably and unfortunately, to be centered on the accuracy (‘is Java truly successful?’) or inaccuracy (Java is everywhere) of the prediction itself.  I feel it is a much more interesting exercise to take the opportunity to go into the author’s opinions as representative of an advanced technologist, and to see what factors would lead a like-minded and influential technologist to potentially have the same negative reaction to a new tool/language based on relatively non-technical factors.  Every day we read articles that are highly critical of languages, frameworks, design patterns, and anything else you can imagine, and it can be difficult to tell how much experience the author may actually have (or even need) to make such assertions.  When an industry voice writes an opinion on a topic based on the factors listed by Graham, what weight is given to the conclusions by the community?  Graham’s article is somewhat unique in that he was willing to list the ‘smell’ reasons for his suspicion.

Looking at each reason Graham gave individually may give us some insight into how technologists yesterday and today may form opinions about a variety of topics, and whether or not we can use these tests to determine future success.

1. It has been so energetically hyped.

While it is certainly true that excessive hype can be a sign of any potential product’s weakness, that certainly isn’t always the case.  Graham mentions notes that ‘A real standard tends to be already established by the time most people hear about it’.  You will find that almost every technology that is highly criticized has been blessed/cursed with a fair amount of hype, either generated by marketing people with profit motive or evangelists that may have much smaller (or even zero) financial interests.  I’m not sure that hype alone should make technologists wary about a new offering, but people who are naturally skeptical will surely be wary of over-the-top hype efforts.

2. It’s aimed low.

This one seems to have some merit.  In this case Graham is saying that Java is intentionally dumbed down, and that ‘Java’s designers were consciously designing a product for people not as smart as them. Historically, languages designed for other people to use have been bad: Cobol, PL/I, Pascal, Ada, C++. The good languages have been those that were designed for their own creators: C, Perl, Smalltalk, Lisp.‘

When people create a product/tool for other people to use, they obviously want their audience to be able to learn it, and Graham seems to argue that by ‘aiming low’ and focusing on ease of use you are probably placing unnecessary limitations on the product you are building.  If you were creating based solely on the need to solve specific problems, ease of use would not be as great a factor.

3. It has ulterior motives.

In this case Graham is speaking of Sun’s plan to ‘undermine‘ Microsoft.  We could certainly apply some tests of ulterior motives to several new developments in tech over the past several years, but I’d imagine it would be a difficult task to find similar motives in the overwhelming majority of new products.  This one is probably, in most cases, not applicable.

4. No one loves it.

Ouch!  Every language, every tool, is loved by someone.  Remember all those people in #1 above that make up the hype machine?  Perhaps by saying ‘I’ve never heard anyone say that they loved Java‘, Graham meant that that no one of any influence or importance loves it.  If a product is eschewed by the most widely respected folks in industry, that is a warning sign.  When some thought leaders begin to endorse tools they become viable for others to adopt (see alternative JVM programming language adoption by big firms today).  Some former Java evangelists professing a love for Scala comes to mind.

5. People are forced to use it.

Being told that you have to use a tool does not make it questionable, but in Graham’s brief description he infers that the anecdotal evidence includes smart people that would have used the tool voluntarily if it were good.  This is probably better said as ‘Outside forces with potentially differing objectives force technologists to use it against the techie’s own better judgement.’  It’s hard to argue with that.

6. It has too many cooks.

This one is quite interesting, especially with the changes that have occurred in the industry since 2001 and the emergence of open source as a dominant player in the market.  Graham went on to write that ‘the best programming languages have been developed by small groups. Java seems to be run by a committee. If it turns out to be a good language, it will be the first time in history that a committee has designed a good language.‘

Issues with the JCP over the years have been written about ad nauseam.  But what would Graham make of other open source developments over the years?  I imagine the rebuttal would be that only the highest level members of an open source project are truly the ‘cooks’ he refers to, with the rest of the members merely relegated to chopping and slicing.  Maybe not.  Being suspicious of multiple decision-makers pandering to multiple masters would be natural, and warranted.

7. It’s bureaucratic.

In this case Graham is referring to the language structure itself and not the leadership.  This can be perhaps lumped into #2 It’s aimed low although not in every instance.  If a language is ‘aimed low’, you might expect that the designers would try and limit the types of mistakes users could make (see #9 as well).

8. It’s pseudo-hip.

Interesting perspective.  I’d argue it was hip.  Graham continued, ‘Sun now pretends that Java is a grassroots, open-source language effort like Perl or Python. This one just happens to be controlled by a giant company. So the language is likely to have the same drab clunkiness as anything else that comes out of a big company.‘

I couldn’t help but notice the words Graham uses to critique Java in 2001 are very similar to how Democrats paint the modern day Tea Party (an observation on the language, not a political statement).  The real meat of this criticism seems to be that the product is controlled by a large organization, which per Graham would by default make it ‘clunky’, but posing as a much more community-friendly and open option.  I’m guessing this element of Graham’s opinion would have been amplified dramatically after the Oracle acquisition.  Would hackers feel differently if a big company tool wore the corporate badge proudly?

9. It’s designed for large organizations.

Graham specifies that Java was designed to limit large teams of mediocre programmers from causing damage.  This seems very much like reasons #2 It’s aimed low and #7 It’s bureaucratic above.  This is probably more accurately categorized as ‘designed for mediocre programmers‘.  I would assume that any advanced technologist would probably be less interested in a tool that seems to be created for a lesser engineer.  Graham wants only languages for big boys and girls, and most advanced and even intermediate hackers would probably agree.

10. The wrong people like it.

Graham lists the wrong people as ‘suits’ tuned into the hype from #1, big company programmers from #9, and college kids looking to get a job.  He feels that all three of these groups change their minds regularly.  I’d say the college kids of 2012 appear to be interested in newer technologies (Ruby, Python, functional programming, mobile) that are probably not the core of their curriculum (Java), and in 2001 they were also interested in newer technologies (Java) that were also not the focus of their education (C/C++).  Does the interest of college grads in Ruby and Python make those tools the wrong tools, or do today’s college grads have a bit more of a sophisticated hacker palate?  What do the suits and big company programmers love today?  Tools with ample talent supply, maybe?

11. Its daddy is in a pinch.

Java’s OLD daddy was, but Java’s new daddy buys islands!  But this isn’t about Java.  The financial standing of the steward of a language or product is certainly a valid consideration to make when evaluating the future viability regarding use in developing a product.  But who would be deemed the daddy of open source tools?  Individual project owners perhaps?  The vendor ecosystem that supports them?  The landscape has changed enough since 2001 that this criticism might be less of a factor now.

12. The DoD likes it.

Guilt by association, and Graham calls DoD culture the ‘opposite‘ of hacker culture.  In some recent discussions about Java and alternative JVM languages, I’ve seen this discrimination used in reverse, where Java supporters claim that the use of the alternative JVM languages by start-ups is a strike against using the alternative options.  The argument is that start-ups are all run by kids and cowboys, so any choices they make can’t be grounded in solid technical judgment.  Interesting how two groups, who both probably feel they are above-average technologists, can come up with opposite interpretations.

CONCLUSION

If you made it to the very bottom of Graham’s post, there is a link to an article called Trevor Re: Java’s Cover, which refers to comments by Trevor Blackwell (also a YC partner) about the post.  Blackwell classifies programmers as either ‘brilliant hackers‘ or ‘corporate drones‘ with most tools being written for the drones, so hackers need to know the smell tests to decipher quickly which tools are meant for the hacker and which were designed for the drones.  Of course, very few of the people Blackwell calls drones probably feel they are in that camp, which just complicates the issues even more.

I feel that Graham’s article is interesting as a time capsule to compare how hackers thought about new tools in 2001 and how they may come to conclusions about languages today.  As an investor, I’m sure some of the same smell tests Graham listed would apply to how he evaluates start-ups for potential funding.  Whether Graham was right or wrong about Java doesn’t matter at all, but getting a glimpse into his thought process then is quite valuable.

How would the current batch of popular and emerging technologies fair today, using Graham’s microscope?

If you found this post useful, you may find my ebook Job Tips For GEEKS: The Job Search even more helpful.  You can follow Job Tips For Geeks on Facebook, Twitter, or Google+.

Lessons From a JUG Talk With Eric ‘ESR’ Raymond

(full video of ESR’s presentation from YouTube below this post)

I have been President of the Philadelphia Area Java Users’ Group for 12 years, and as one might expect a typical meeting is geared around a presenter with a slide deck that gives a deep dive into some Java topic.  We could hear a case study, an explanation of a tool, tips for programming effectiveness, etc.   The JUG has followed this model since I founded the group in 2000, and we manage to get between 75-150 attendees at most meetings.

Last month we held a meeting that was entirely different.  I had reached out to Eric Raymond (aka ‘ESR’), who is best known as a leader in the open source software movement and author of The Cathedral and the Bazaar, about potentially speaking to the group.  Although ESR is not commonly associated with Java, I thought it would be an opportunity for the group to hear a well-known and respected engineer speak about a topic.  ESR suggested that he would do a free-form type presentation, without notes and slides, and simply take questions from the audience to use as improv material.  With about 150 engineers in attendance, ESR fielded a fairly wide array of questions on everything from functional languages to open source licensing to coding standards.

So why am I posting this article on JobTipsForGeeks?  As a recruiter I am often asked for career advice by my network of engineers, and my answers are always based much more on market trends (supply and demand) and ‘buzz’ around various technologies than on the viability of the technologies themselves.  For example, I am well qualified to discuss the adoption of specific languages by software companies in my region, but I am much less qualified to discuss the long-term viability of those adoption choices from a technical viewpoint.

As ESR was asked some of the same questions I am often asked, I thought his answers and insights were an opportunity for the audience to hear a ‘technically-grounded’ counterpoint (or supporting evidence) to the market-based advice I provide to individuals.  His specific commentary on functional programming languages and the value of learning them regardless of adoption rate was something I thought was insightful advice for engineers of all levels, and his musings on coding standards and how to obtain management ‘buy-in’ on open source are great tips for navigating at companies that may not be as tech-friendly as others.  These are not all specifically ‘job tips’, but I believe there is certainly some value in reading these opinions as you decide on which directions you may take your software career.

The quotes below are ESR’s responses to questions, organized by topic.

ON PYTHON
“Yes, I really like Python.  I like it for a very specific reason.  I like Python because of all the languages I have ever used, it is the one that maximizes ease of long term maintainability.  That is, the ease with which you can read your code six months later.  The longer I program, the more convinced I am that that is THE most important metric of a language, bar none… Most of the programming I do these days is in either Python or C.”

ON JAVA
“I still haven’t actually learned Java well enough to do more than a couple hundred lines of programming in it.  I don’t dislike Java but I think it is a little over-verbose, it’s become kind of top heavy.  So it’s not my first choice, but if I had to write something in Java I wouldn’t go ‘ICK’.

ON C++
“C++ has the exact opposite problem to the virtue I had called out in Python.  Long-term maintainability of C++ code, TERRIBLE.”

ON PERL (answer continues from his answer on C++ above)
“OK, the best thing I can say about that is, it’s not as bad as Perl, but I’m afraid that constitutes damning with faint praise.  I still like Perl fine and occasionally use it, as long as the program isn’t more than 25 lines long.”

ON GOOGLE GO
“I am sort of gingerly dipping my toes into the waters of Go, Google’s new language… I’ll tell you one concurrency thing I am really pleased by.  I have been wondering since about 1971 why nobody took the ball and ran with Hoare’s communicating sequential processes model.  So elegant, so pretty, so nice to reason about and 40 years later the Go people picked it up and ran with it.  That’s one reason I’m looking at Go.  CSP is the basis of their concurrency model in that language which is enough to motivate me to want to look at it some more.”

THOUGHTS ON THE JVM BECOMING MORE GENERAL PURPOSE
“I’m mostly ok with that.  I think the JVM has some deficiencies near word length and there are some serious problems with the numerical tower…It needs some work to be a really robust platform, it’s good but not as good as it needs to be.”

ON RUBY 
“I’ve dipped into Ruby a little bit, there was a point where I had to modify some Ruby code for a project I was working on, so I think I understand the language a little, maybe not master level.  My impression of Ruby is that it has pretty much the same virtues and the same problems as Python, and I might be tempted to switch except that it’s not different enough.  Functionally speaking of course, I mean aesthetically there is all kinds of odd little differences.  But it’s not different enough from Python to make me move, that’s my impression.”

ON SCALA
“It’s on my list of languages to learn.  I have a friend whose judgment I trust who says it is a very good design, and that’s enough reason for me to go look at it.”

ON OPEN SOURCE LICENSING/GPL
“…this is one of my more incendiary opinions, I don’t think we need the GPL anymore…My attitude in general is just use permissive licenses, stop with the viral stuff…”

ON OPEN SOURCE 
“If you’re thinking in terms of bringing open source inside the corporation, you’ve already failed.  That is already thinking in the wrong direction because you’re trying to figure out how to control and make safe a process that thrives on lack of control and no safety, other than good code review.  Instead of thinking about how to bring open source inside the corporation, the right kind of question to ask is ‘how do I start up an open source project that benefits my corporation, build a community, and THEN sell it to my bosses?’.  Because one of the iron laws of dealing with bureaucracy is ‘it is easier to get forgiveness than permission’…How do I start an open source project that will interest my bosses, get it viable, and then sell it to them once they have a benefit that they can see?…Show them a benefit.  Don’t say ‘we can do this wonderful thing if you authorize me to spend n hours with no obvious physical return’.  That is something a manager is always going to say ‘no’ to.  What you have to do is show them a benefit.  It works much better, for example, to find an existing piece of open source software that is fairly close to solving the business problem and going to your boss and saying ‘you know, this thing already works and already has a user community and I can show you where it’s deployed, give me 50 hours and I can turn it into something that will solve our problem too’.  At that point you have a much better pitch, because that’s the kind of trade-off your manager is used to thinking about.”

ON OPEN SOURCING PRODUCTS DEVELOPED IN-HOUSE
“The universal argument that works for that is to say ‘hey boss, how would you like to reduce your maintenance costs?’.  Lay off the work on other people so it’s not coming out of your budget.  That’s the reason for open sourcing stuff that was developed in-house.  The argument for that is cost-spreading and risk-spreading.  And you want to put it exactly that way, ‘hey look, I’m going to reduce your bottom-line expenses’.”

PROS AND CONS OF CODING STANDARDS
“My first overarching observation is that the smartest thing you can do is choose a language in which coding standards are not necessary because there’s a uniform style that the language semi-enforces.  Yes I have Python in mind.  Go also has this property, it’s very difficult to have indent style variations in Go…The smartest thing you can do if all other things are equal is pick a language where you will never have coding standards wars.  The reason that that is a high-utility thing to do is, of course, the purpose of coding standards is to maximize readability of the code and long-term maintainability.  And yes, I do think that is extremely important… in particular if you are writing in C, the thing to do is pick a coding standard but don’t try and be too anal about it.  There comes a point at which the effort to enforce every conformance to every minutiae of a coding standard is causing you more pain and overhead than it is actually worth in reduced maintenance costs.”

THOUGHTS ON LISP/FUNCTIONAL PROGRAMMING
“There’s a can of worms.  The first thing you need to know about me in this connection is I’m an old Lisphead…I actually cut my teeth on APL…The result of the first two languages that I learned is I have this mental measure of a programming language’s adhesiveness.  A programming language is adhesive to the degree that it sticks to your brain and cannot be displaced from your brain except by a language that is more adhesive.  I learned APL first, and then I got exposed to Lisp…My first question was ‘which one is more powerful in a practical sense?’, and yes, yes I know they are all Turing equivalent…So I decided to test the question by writing two toy implementations.  One of an APL interpreter in Lisp, and one of a Lisp interpreter in APL…That is why I switched to Lisp, and discovered that Lisp is more adhesive than APL, and it displaced APL from my brain.  Nothing has displaced Lisp from my brain.  I have not encountered any language that is more adhesive than Lisp.  Which is not to say I use Lisp a whole lot, but that it still dominates the way I think about programming.”

ON HASKELL
“I dipped my toes into Haskell, and someday I’ll have to do a significant project in Haskell.  But that time is not yet though.  I haven’t found anything for which it is better than the tools I’m already using.  The problem with languages like Haskell…and I have digested dozens and dozens of computer languages in my time and I used to be a mathematician with a specialty in formal and foundational logic.  With all these credentials, Haskell makes my brain hurt.  So if Haskell and other pure functional programming languages make your brain hurt, that’s ok.  And the thing that worries me about them, is that if they make MY brain hurt, how the hell are they going to make any traction with people who didn’t used to be foundational logicians with a specialization in logic.”

ON FUNCTIONAL LANGUAGES
“My worry is that these are beautiful tools that will never actually achieve mass acceptance because they are simply too hard for most programmers to use.  The question is, what is the attraction then?  For the class of problems that is easily addressed using a functional language, using functional languages produces solutions that are breathtakingly, devastatingly elegant, beautiful and terse.  When the tool matches the problem, there are very few things in the universe more lovely than a properly designed functional program.  The issue though, is ‘A’ – that the tools are difficult to comprehend, and ‘B’ – I said ‘when the problem matches the tool’, there are lots of problems that don’t match functional programming language tools because functional programming language tools really want to live in a universe where everything is stateless and all transactions are reversible.  Uh oh.  You run into problems with those assumptions the moment you deal with messy things like input/output operations…intrinsically not reversible.  A lot of the complexity in functional programming languages arises from this unavoidable interface, this energy barrier between the programming language’s internal world of pure logic, statelessness and reversibility and infinite backtracking, and the messy exterior world where we actually have to deal with stateful objects…They are fascinating tools, they are good for some classes of problems, I love them aesthetically.  I don’t know if they will ever be more than a small minority preference.”

ON LEARNING FUNCTIONAL LANGUAGES
“Nevertheless, even though these tools may never get huge traction, learn one anyway.  When you get deep enough into any functional language, for me it happened with Lisp…there will come a point at which you will achieve Satori, you will achieve enlightenment about how functional programming actually works and your entire universe will lurch sideways and never be quite the same again.  And even if you never use a functional programming language for a line of code after that, it will change the way you think, it will change the way you form abstractions, it will clean things up.”

ON JAVA AND PYTHON SEEMING MORE FUNCTIONAL
“Ironically in the case of Python, Guido actually doesn’t like Lisp and his personal preference would be to take the functional constructs out of the language (Python), but every time he does that a bunch of his friends and senior developers, including me, look at him and say ‘you will take away my lambdas when you pry them from my cold dead fingers’.”

PYTHON VS JAVA 
“The advantage of Python over Java is that it’s less heavyweight, there isn’t a huge syntactic thicket of declarations and codicils and stuff that from a point of view of a Python programmer is extraneous junk that gets in the way of comprehension.  There are languages that are much worse that way, see my rant about C++.  Java is a bit too syntax-heavy and cluttered for optimum long-term maintainability.  That is my opinion anyway.”

OPEN SOURCE
“We now live in a situation where lots of people can use and enjoy open source tools and an increasing number of people can make a living writing and maintaining them, and that’s a good thing.  Do I want to see all software become non-proprietary?  It wouldn’t particularly bother me if that happened but it’s not a major objective for me.  It doesn’t harm me that other people write proprietary software as long as they don’t try to infringe on my freedom to write software the way I want to.  That’s the freedom I’m concerned with protecting.  I want people who voluntarily choose to be part of the open source community to be able to continue to be a part of it, and as long that objective is achieved, what other people do is not really of much concern to me.”

Your comments are welcomed below, thanks for reading.