- They finally found all those buried Atari cartridges, and confirmed a beloved urban legend. Just wonderful.
- This episode of @ExtraCreditz follows up an idea I always had about education. The key is being demanding, but allowing a lot of opportunities.
- Amazing book introduction, showing how no one is immune to think that they are stupid. Lots of things in live are hard.
- Readability in code is not about being literary. Is about making the code easy to understand. You don’t read code, you explore it.
- The Great Works of Software. The premise is extremely interesting. What are the most influential pieces of software?
- The hilarious (is funny because it’s true) Programming Sucks and a follow-up What programming is Like.
- Is programming a dead end job? I still can’t help but feel sad each time that a (good) developer decides to move into management.
- It’s easy to forget how much the things have changed in term of software distribution. What Writing and Selling Software Was Like in the 80’s (yep, also from The Codist. You should subscribe)
- The computer world is very dominated by English, and even so with latin alphabet. This idea about making a computer language in Arabic is fascinating. It not only shows how difficult is to set up an environment without problems out of “the ASCII world” (the magnitude is not comparable, but trying to code in languages like French or Spanish has a lot of friction), but it also shows up how alien (yet beautiful) a different alphabet looks. I wonder how code and programming will be if the dominant language would’ve been something like Chinese or Arabic.
- What is the “Agile mindset” anyway? The graph is very interesting. Specially the “Chaos labeled as Agile” side.
- I don’t really like the idea of “rivalry” against Vim and Emacs. I prefer to consider them two valid options. But this article goes into explaining their different appeals and why they have been around since an extremely long time ago in computer-years.
- 10 Most common Python mistakes. Good to check.
I saw yesterday live the Apple keynote on the WWDC. I am far from an Apple developer, but I use OS X and iOS everyday, and I’m interested on new stuff. There was a full section devoted to developers, which is great (well, it’s supposed to be a developer’s conference, after all), and, arguably, the most interesting stuff on that part (for a developer’s perspective) was the release of a new programming language, Swift.
It was announced with an (irrelevant) comparison with Python in terms of speed (I actually have plans to write a post about “why Python is not really slow“, but I digress), as well as a lot of other details that (IMO) are completely pointless in terms of what makes a good or bad programming language.
I am generally skeptic about the announcement of new languages. Almost as much as new web frameworks. Sure, it adds a new flavour, but I’m not that sure about real advancement in tech. Creating a new language, full with proper “clean and beautiful” syntax is not really that difficult. The difficult part is to create a vibrant community behind it, one that loves the language and works to expand it, to push the boundaries of current tech, to make amazing applications and tools, to convince other developers to use it and to carry on the torch. The target of a language are developers. “End customers” couldn’t care less about how the guts of their products are done. “Ruby sharp? Whatever, I just need that it help us increase our sales“
Interestingly enough, languages get a lot of character from their communities, as they embed their values on the relevant modules and tools. A great example of that is “The Zen Of Python“. There’s nothing there about whitespaces, list comprehensions or classes, but it reflects a lot of the ideas that are common on the Python world, values of the Python Community. Using a language is not just writing code, but also interacting with other developers, directly or even just reading the documents and using the APIs.
Obviously, Apple is a very special situation, as it can force developers to use whatever they like for their platform. Hey, they managed to create an Objective-C ecosystem out from nowhere, which is impressive. For what is worth, they can even tailor a language for their platform, and not to worry about anything else. iOS is a platform big enough for devs to have to learn the language and official IDE and use it. And I am pretty sure that in this case it will be an improvement over the previous environment.
But the one part that I am most skeptic about is the “visual programming” stuff. One of the “wow” announcements was the possibility of creating “playgrounds”, to show interactively the results of the code. That means that, for example, a loaded image will be available, or that a graph can be displayed showing the results of a function. And that’s the part that I’m not really that sure that is interesting or relevant at all.
Does it look cool? Absolutely. May it be interesting once in a while? Sure. But I think that’s the kind of process that, in day to day operation, is not really that useful in most kinds of programming.
Programming, more than anything else, is creating a mental image of code. Code can be a very complex thing. Especially on a big application. But normally we don’t need to keep the whole code in our mind. We only have to keep certain parts of it, allowing to focus in a problem at a time. That’s the main principle behind modules, classes and other abstractions. I can use OS calls to open a file, to draw some pixels on the screen, or to make a call to a remote server. All of that without having to worry about file systems, graphic drivers or network protocols. And I can also use higher level modules to search on files, create 3d models or make HTTPS calls.
And the amazing power of programming is that you are coding on the shoulders of giants. And on the shoulders of regular people. And on the shoulders of your co-workers. And on your own shoulders. That’s a lot of shoulders combined.
But a lot of that process deals with the unavoidable complexity of the interaction. And being able to move from an abstracted view to a more specific one, to look inside and outside the black box, is crucial. It may not be evident, but the mental process of programming deals a lot with that sudden change in perspective. This is one of the reasons of multiparadigm being a useful thing. Because you can move between different abstractions and levels, using the proper one on each case (especially for leaky ones).
And there are lots of those processes that are not easily represented with graphs or images. They are constructs on your mind: loops, flexible structures, intuitions on the weak points of an algorithm, variables changing values, corner cases… Showing all intermediate results may be detrimental to that quick change in perspective. Too much information.
There has been experiments with visual programming, trying to represent code as visual blocks in one way or another, since a long time ago (at least 25 years). They are useful in certain areas, but they are far from a general solution. There are also interactive notepads to allow easy display of graphs and help with the interactivity. iPython Notebook is an excellent example (and a very similar idea to the playground). But, again, I feel that those are specialised tools, not something that is that useful in most programming contexts.
I’m just skeptic. All of this doesn’t necessarily means that Swift is bad, or that those tools are wrong. Maybe the new X-Code will have a lot of amazing tools that will help create fantastic applications (I still don’t like IDEs, though). There are already people checking the docs and giving a try to the new language. But I think that it has to show up how good or bad it is for itself, and by the developers that decide to use it. So far, it is just an announcement. I just feel that most that was said on the keynote was not relevant to determine whether it’s a good working environment or not, but was just a gimmick. Yes, obviously these kind of announcements are publicity stunts, but in this particular case it looks especially so.
Looks cool, but is not particularly relevant to how the mental process of programming works or what makes a language good.
- Seven habits of effective text editing. A great essay by Bram Moolenaar (of Vim fame). It is applicable to any editor, but, of course, shows why Vim can be such a good choice (once you know how to use it, obviously)
- A useful collection of recipes in Python. Thirty python language features and tricks you may not know
- How to be a sane programmer. Basically, do other stuff not related to programming. The related Business Insider article is also worth the read.
- The Evolution of a Software Engineer
- D/A and A/D Digital Show and tell. Great explanation on how sampling and analog conversion works. I spent my college years dealing with this stuff (and using the same equipment), it is explained beautifully.
- 10 important URLs that every single Google user needs to know Interesting stuff about privacy and Google.
- A glass breaking recorded at high speed.
- How to Create an Awesome Candidate Experience. On thing that I particularly liked about it is the fact that it acknowledges how emotionally exhausting is to go through a recruitment process for the candidate.
- Game servers UDP vs TCP. great article about the differences between TCP and UDP, usually not well understood.
- Amazing precision. The art of Street Typography.
- I love this quote: “I do not want to be a “rock star”. I want to be a good engineer on a great engineering team“. I talked previously about this, and how a great team will be much more productive than a bunch of “Ninja Developers”.
- Good tech lead, bad tech lead.
- Can we please please stop telling people that coding is easy?
- Confessions of an Intermediate Programmer. The perception and psychology of competence.
- The Science of Making your Story Memorable Some interesting advice about presentations. The presentation itself used as example is interesting as well.
- Thirty percent feedback to iterate faster.
- The classic “your problem with Vim is that you don’t grok vi” response in Stack Overflow.
- A very nice list of Python articles. Best Python 2013
- Companies and startups are different. Not only in size, but qualitatively. An startup is based on the search for a business model, while a company is based on the execution of a business model.
- A typewriter to print water paints. Amazing.
- How much is time wrong around the world, actually meaning how places in the world are synchronised to “12 AM when sun is higher”.
- A reflection about how Internet is so full of strong emotions and is so judgmental.
- When It’s your job to give bad news, because we don’t live in an ideal world.
- Writing is hard.
- This is a wonderful comment (in Hacker News)
- A great initiative to clean up Vim code. Neovim. It includes a fundraiser to help in the initial phase.
I had a conversation last November on the PyConEs, when I was on a conversation stating that I am working with truly brilliant people in DemonWare, and then someone asked me: “Do you have problems agreeing in what to do? Normally great developers have problems reaching consensus on tech discussions”. My answer something like: “Well, in my experience, truly awesome developers know when to have a strong argument and they usually are ok reaching an agreement in a reasonable time”.
So, I wanted to, as sort of follow-up, summarise what are the characteristics that I’ve seen in the best developers I’ve been lucky to work with. This is not a list I am making on “what’s my ideal developer”, but more a reflexion on the common traits I’ve seen on my experience…
- Awesome developers are obviously smart, but that’s not typically shown as bursts of brilliance, solving really difficult issues with “aha!” moments. In my experience, genius ideas are rarely required nor expressed (though they surely happen once in a blue moon). Instead, great developers are consistently smart. They present solutions to problems that are reasonable all the time. They find and fix typical bugs with ease. They struggle with very difficult problems, but are able to deal with them. They are able to quickly present something that will make you say “Actually that’s a nice point. Why didn’t I think about this?”. They do not typically present something ingenious and never heard of, but deliver perfectly fine working ideas over and over, one day after another. Their code is not full of mind blowing concepts, but it is logical, clean and easy to follow most the time (and when’s not, there is a good reason). They are able to remove complexity and simplify stuff, to a degree that it almost look easy (but it’s not)
- They keep a lot of relevant information on their minds. They are able to relate something that is in discussion with something that happened three months ago. They seem to have the extraordinary ability of getting out of the hat some weird knowledge that is applicable to the current problem.
- While they have a passion for coding, it is not the only thing in their lives. They have hobbies and interests, and they don’t usually go home in the weekends to keep working on open source all day, though they may occasionally do.
- They love to do things “the right way”, but even more than that, they love to make things work. This means that they will use tools they consider inferior to achieve something if it’s the best/most convenient way. They’ll complain and will try to change it, but deliver will be more important that being right. They have strong opinions about what language/framework/way of doing stuff is best, being that Python, Ruby, Haskell, PostgreSQL, Riak or COBOL, but that won’t stop them knowing when it’s important to just stop arguing and do it.
- They are humble. They are confident most of the times, but far from arrogant. My impression is that they don’t think that they are as awesome as they truly are. They will want to learn from everyone else, and ask when they have questions. They will also catch new ideas very fast. They are also friendly and nice.
- Communication is among their best skills. They are very good communications, especially, but not limited, about tech issues. They may be a little social awkward sometimes (though this is not as common as stereotypes portrait), but when they have the motivation to express some idea, they’ll do it very clearly.
- In some of the truly remarkable cases, they’ll be able to fulfil different roles, when needed. I mean different roles in the most broad sense, basically being able to be what’s needed for that particular moment. Sometimes they’ll have to be leaders, sometimes they’ll be ok being led. They’ll know when a joke is the proper thing to do and when to remain formal. They’ll be the person that helps you with a difficult technical question, or the one that will tell you “you’re tired, just go home and tomorrow it will be another day”
- And they’ll have a great sense of humour. I know that almost everyone thinks that they have a good sense of humour. That’s not totally true.
Again, this is sort of a personal collection of traits based in my experience and on what I consider the best developers I’ve been honoured to work with. Any ideas?
Ever since I was a young boy,
I typed on keyboards
From bash commands to Java
I must have code them all
but I ain’t seen nothing like him
In any Hackathon
That nice, nerd and shy kid
Sure codes great Python!
He stands like a statue,
Becomes part of the machine.
Lots of comprehensions
always writing clean
right code indentation
dicts used the most
That nice, nerd and shy kid
Sure codes great Python!
He’s a coding wizard
There has to be a twist.
A coding wizard,
S’got such a supple wrist.
How do you think he does it?
I don’t know!
What makes him so good?
ain’t got no distractions
semicolons or brackets
Nice packaged modules
when it fits the best
That nice, nerd and shy kid
Sure codes great Python!
I thought I was
The system admin king.
But I just handed
My hacker crown to him.
Even on my favorite system
He can beat my best.
Opens the text editor
And he just does the rest
He’s got crazy vi fingers
no IDE at all
That nice, nerd and shy kid
Sure codes great Python!
Another year, another amazing PyCon. I guess I repeat myself, but I keep being impressed about the quality of the talks and the friendly, vibrant atmosphere. It is always a pleasure to spend some time with people interested in code and technology… There was also an increase in the number attendees, and quite a lot students. I said that on Twitter, but Python Ireland, you guys rock.
Of all the talks I attend to, I’d like to comment two that were especially interesting. The first was one of the keynotes, PRISM-as-a-Service: Not Subject to American Law, by Lynn Root. All this think is pretty scary when you think about it. Definitively worth a read. The other one was The Clean Architecture in Python, by Brandon Rhodes, about ways of designing code and make them data-centric.
I also gave a talk, and other than a problem with the project that made me rush a little, I think it went good. Just in case you’re interested, here are the slides. Here is also the PDF version with notes.
Oh, and another thing. there are launching the pyLadies Dublin group this wednesday 15th October, so if you’re interested, show up.
UPDATE: Added slides for Brandon Rhodes talk
There has been some discussion about the so-called Rockstar Programmer. You know, that awesome engineer (also called 10x engineer) that can produce what 10 other, average engineers can.
That resonates a lot, because I think that we should agree that, while there is people with potential to be ninja programmers, that’s not something that can be achieved without the proper care on the environment.
A good team is one that reinforces the good points of their members while hiding away (or at least mitigating) their weaknesses. It makes not sense to talk about a guru engineer that can come in a parachute in a project (any project), replacing an average Joe on a 10 members team, and simply double their output! And, after a while, she’s probably take her umbrella and fly away to the sunset (to a better payed work, one can only imagine)
Real life just doesn’t work like that. Everything is a little more complex. A toxic team or project can be beyond salvation. A regular programmer can achieve a lot just by giving some motivation and direction. A great engineer can be disastrous working in a particular area.
Do you want to see someone transformed from an x programmer to a Nx programmer? Just take a look on the same engineer the first day in a new job and then again after a whole year. The first day she’ll have to ask lots of questions. After a while, she’ll be committing patches, and, later, she’ll reach a cruise speed much much faster than the first couple of days. Or… maybe she is an x programmer, and during the first days she was a x/N programmer. Mmmm….
I also like how Haselman he approaches the subject talking about “titles” and “loud programmers”. The Rockstar Engineer idea is more a recruitment-marketing issue. It is used to hype possible hires: “Hey, we are a Rockstar company and we are looking for Ninja developers. Maybe you’re an Stellar Programmer”. It has been so used that it doesn’t mean anything anymore. I’ve even seen a job offer asking for a Python Admiral. It is currently more a way of signalling spam than any other thing. 
But there is still the myth of “the 10x programmer”, not as a way of describing that there are obviously people more productive than other (and who can reach high notes), but taking for granted that is mostly a characteristic of the programmer itself, while the truly stelar results are achieved mostly when the environment is the adequate. A lot of the great results in a team is not a magical increase in productivity by some gifted individual, but more the constant improvements in the good directions or good vision to focus in what’s truly relevant. A single good developer can move quite fast in the good direction not because she’s wildly more productive but because she has a clear view and focus.
Because an average programmer can be at least a 5x programmer when the proper details fall in place, and a great developer can be a 1/5x programmer in the wrong place.
1 – He’s also referencing this very interesting article by Shanley.
There are a lot of discussion about how to make Vim “an IDE”. Vim is a great text editor, but when we are developing, there are lots of extra tools that are very useful. Code completion. Easy navigation through files and classes. Source control integration. Syntax checking. Navigation that understand the semantics. Integrated debugger.
My problem with IDEs (and I have used a few over the years) is that they give you a lot of support, but at the cost of increasing the complexity. They are slow for a lot of common operations and they use a lot of resources. Code completion, the good kind that will allow you to get the types of a method, not just finish your words (which most of the time is trivial), is useful when developing on a static language, but since I program in Python is something that I can’t find good use of it. I just don’t use all that stuff, so I don’t feel I can justify to pay the price.
Another problem with IDEs is that they tend to be designed, by default, to the newbie. That’s not necessarily a bad thing, Vim is a pretty intimidating tool because is totally crazy for the rookie. But it generates a bloated environment to start with. If you open Eclipse, a popular IDE (and one I’ve used for some years), you’ll get a relatively small frame for the code, and a lot of extra stuff surrounding it. Logs, file navigation, class definition, a huge toolbar, maybe even a TO DO list…
For example, think about file navigation. Sure, it’s useful to move around. But it is used only at certain points in time. Most of the time, it’s just used as an entry point to code, and then the navigation can be achieved, either just moving around in the same file, by a referral from the code (like going to a method definition), or just searching on the whole project. In case you need to go to an specific file, you can then show the navigation window, or even better, search by filename. That only happens during small periods of time, so the rest of the time the window is just wasted space on screen. The same thing happen for a task list. It is useful to know the next step. But not while you’re working in one task.
Hey, it is possible to hide the navigation window, and display it only at the proper moment, to save space. I have done that. But it’s not there by default, so most of the people I know just keep it open “just in case, giving context”. They just get used to it, and don’t perceive it as a problem, But having half of your screen full of information that is irrelevant 95% of the time is a huge price to pay. And certainly not a good use of an IDE. The good parts of an IDE are things like automatic compilation and deployment, refactoring tools (not just renaming), debugging, help with the types in static languages, automatic generation of code, etc. Not showing everything, all the time.
Vim is a text editor, but it is also sort of a philosophy. It is not about showing stuff, but about having stuff available at the right moment, with a quick command. It is not just about using hjkl to move around and having an insert mode. It’s about being precise. It is difficult at first, because you can’t simply discover what are the available options, but it also pays off in terms of focus and clean environment. When programming, the most important part is to keep as few things into mind as possible. Keeping all relevant information, which is already enough, but nothing more than can distract you for the task. It is also about doing one thing, and not a hundred. I use other tools for things like source control and debugging. After all, we have the whole OS to work as our IDE.
I use a small number of plugins in Vim. When you learn a little about it, you find out that it’s amazing the number of features and stuff that can be achieved “out of the box”, and how little extra is actually needed to have a really productive environment. It’s just that we need to move from the usual “browse through menus” world that most of software uses, and devout some time to, well, study and learn. It’s really worth it.
My first computer was a second hand ZX Spectrum+ This says a lot about my age, I guess. I got it from my uncle, who bought himself a more powerful computer. I really loved that computer, and used it for quite a long time. It seemed so magical that you could play a tape, which sounded weird, and load a game. There was also the possibility of program from the command line, which I tried, but I never “got” exactly how to get from very basic stuff to anywhere.
A few years later, and after the Spectrum was broken, I obtain a PC. At first without a sound card, so it was strangely silent compared to the computers of my friends. But the change to a hard drive, where the load times were almost instantaneous was astonishing. Yes, there were disks, but even load something from disk was extremely fast compared to the 15 minutes to load from tape. The usage of MS-DOS was also magical. Learning all the commands, messing around with configuration options (differences between extended and expanded memory) on autoexec.bat and config.sys and even changing port jumpers physically on the cards to resolve problems.
When Plug And Play arrived, at Windows 95, most of the pain seem to disappear and configuration worked fine most of the time. Also having multitask and a GUI was amazing. Around the same time I got my first experience with Internet. Suddenly, there was a way to obtain information not from disks (or CDs), but from a network. It was a slap in the face, and I immediately understood that it was going to be a basic part of the future, as it is today. I think that was obvious to any one interested in computers. It took a considerable amount of time to get to a position where it was something common, as it will be charged by time initially and it was expensive.
I started college and learn more interesting, wonderful stuff. For example, UNIX, a “new” (for me, at least) operative system that seem to have the crazy idea of being able to be used for more than a user at the same time. Or the understanding the internals of computers, which got me a lot of “aahhh, now I get it” moments from previous experiences. Including the programming part, which I discovered was much more powerful and interesting than the small scripts I did before.
When I started my first job, I developed for systems that were also computers, but weren’t shaped as a box, an screen and a keyboard. And that you can compile in a machine code for another. I also learned a lot about how powerful and productive was to use properly development tools like IDEs and the Unix command line.
After that, I spend a few years without working as developer, but when I came back, it looked like I missed stuff. Like how incredibly easier to use have Linux came to be, thanks to Ubuntu. So much, that after a problem updating my personal computer, I installed Ubuntu at home and never looked back to Windows (I use a Mac these days). But the thing that impressed me more, Virtual Machines. So you’re saying that I can run a full computer inside my computer? That’s amazing!
I also learned Python (and other scripting languages) and, coming from writing mostly C and C++, you can imagine how wonderfully productive it felt. It also have a really great environment, with modules to do anything that you can imagine. One of my first uses of it was to create an application on an Open Office spreadsheet, including dialogs to input information. I got so in love with Python that I decided to move my career around it.
I got really impressed with the iPad presentation. It really was (and is) a magical device I had dreamed a long time ago. I have an iPad, I use it every day and it is probably my favourite device that I ever owned.
The thing that surprises me it’s that I still have this sense of wonder, of enthusiasm after living all those things. I have seen a lot, but somehow, keep that kid inside me that is amazed by technology and how far have we come, and how the next thing is really great. It’s not easy to perceive on a day-by-day basis if you work in this field, but taking a look back, just as close as 5 years back, things were quite different from now in the lands of technology. The change has also been accelerated. Software, in particular, seems to have flourish in ways that seemed impossible. There are better tools to generate it, that make complex projects to be able to be achieved by small teams in very short amounts of time. I know, there are also complains about how exactly this technological progress is happening, and how 50 years ago we think we were going to be able to live in Mars and to wear jetpacks, but I think that having permanent access to the greatest library on our pockets on devices getting faster and more capable every year is not a small achievement. We live in the future.
I remember all this from time to time, when I am tempted to be cynical on new products, like I’m sure you’ve read these days related to iOS 7, PS4 and/or Xbox One. There seem to be a lot of people that put their best “not impressed” face for almost every new release, and that’s not a good thing. Of course, there are things that I’m not particularly like or am fond of, for example the iPad mini (an smaller iPad? I’d love a bigger one, maintain the weight), but I try to remember that there are people that will love all these things like I loved previous ones. I am not necessarily the ideal customer for everything, and I appreciate when a review is about describing the product and its strong and weak points and not that much about stating a (usually predetermined) opinion.
We are truly living in days of miracle and wonder since almost 26 years ago. I hope you’re enjoying the ride. I certainly am.