Visual Programming and Mental Constructs
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.
Most pointless benchmark ever
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.
As mandatory as honor
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.
Hmph. Visual blocks. Heh. Excitement. Heh. A Developer craves not these things.
Compendium of Wondrous Links vol V
- 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”.
The amazing forgiveness of software
One of the things I like most about developing software is the fact that you can recover from most mistakes with very few long term impact.
Bugs are unavoidable, and most of the people involved on programming deeply understands that is something we all live with. So, there’s no hard feelings, once you find a bug, you fix it and immediately move on. Not only no one thinks that you’re a bad developer because you write bugs, but typically the impact of a bug is not that problematic.
Yes, there are some bugs that are just terrible. And there’s always the risk of losing data or do some catastrophic operation on production. But those are comparatively rare, and with the proper practices, the risk and damage can be reduced. Most on the day to day operation involves mistakes that have a much limited effect. Software development is more about being bold and move fast fixing your mess, than it is to play safe (within limits, of course).
This can affect production data! Display warning sign!
Because the greatness of software is that you can break it on purpose and watch it explode, and then fix that problem. In a controlled environment. Without having to worry about permanent effects or high costs. And a good test is the one that ambushes the code and try to viciously stab it with a poisonous dagger. The one that can hurt. So you know that your system is strong enough against that attack. And then iterate. Quickly. It’s like having a permanent second chance to try again.
Not every aspect of live is that forgiving. I guess that a lot of doctors would love to be able to do the same.
Do you mind if the jury forgets everything and we start the trial again, your honor?
Compendium of Wondrous Links vol IV
- Some gifs showing Vim capabilities. Why I use Vim.
- More about the philosophies behind vim. Why Atom can’t replace vim.
- A browser game, similar to the great Threes for iOS, with a binary twist. 2048 It can be a little addictive, though.
- An this is another brilliant game. Create your own metro system. Mini Metro.
- 3 wrong ways of storing a password and some examples to do it in a more proper way. And more about setting a salted password hashing.
- Don’t be a technical masochist. It is good to have options and recognise best tools for the job.
- An article about the different issues (while mostly stating age on the title) that can be growing on the current “startup culture”. Maybe a little exaggerated in some aspects, but an interesting read nonetheless. Silicon Valley’s Youth Problem
- About Agile as a buzzword and getting back to the core of the Agile manifesto, two related articles: Agile is dead (Long Live Agility) and Agile is Dead: The Angry Developer Version. I write something related to this a while ago.
Let your fellow developers know they’re great
I think that one of the most challenging things in my life as a developer is the Impostor Syndrome. Unless you’re stuck into a mediocre job, where everyone around you is pretty lame (and, believe me, if you’re in that situation, you want to get out as soon as possible), I think it is quite common to get that feeling of “wow, I don’t deserve to be here” feeling from time to time.
I am pretty terrible at myself, and I suspect I am not the only one. If I achieve something, that great feeling of “Oh, yeah!” will wear out after a few hours or days. I still remember sometimes failures I did at High School and feel bad about them. Yep, it sucks.
I have also perceived that it’s more dependent on yourself and team dynamics, that really on how smart people surrounding you is. Currently, I am in an astonishing place to work, where there are plenty of super amazing people. Surely I get impressed with great stuff often. But in previous jobs I had, where people were way less awesome but there were less communication, I felt it even worse.
Probably because we are painfully aware of all our limitations, the times we procrastinate, our failures, our own struggles with stuff that’s hard. But we perceive others more as their successes, their external results and their progress. One of the most common advice when performing live is to learn to “keep going” after a mistake, because it’s more important to continue that to allow that mistake to make you lose focus. With lack of positive reinforcement and seeing how valued is your work, it is very difficult to see your achievements and see yourself as a valuable member of a team.
I am more and more convinced that a great team and a great atmosphere are two of the most important things at job (if not THE most important), as well as in life. After all, we want to be reasonably happy while we’re working. Heck, we deserve to be happy at work.
That’s why I consider that giving good feedback to your co-workers is absolutely capital. Of course, when deserved. Of course, honest. It has to come from the heart. But I’m pretty sure that most of developers out there are way more eager to say and mean it “this is crap” than “this is fantastic“. And it shouldn’t be.
One of your most important duties as a developer is to show appreciation to your fellow co-workers so they know they’re great (and you know they are)
Compendium of Wondrous Links vol III
- 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.
Respect Driven Development
I think that one of the most overlooked components on any sane company culture is Respect. That’s probably true also for any relationship, also outside work environment, but I think is usually forgotten when nice places to work are described.
When I look back about the things that bothered me the most, most of them are related to disrespect, even in relatively minor form. It can be personal disrespect or not respecting the work itself or even the customers. Probably because is something engraved, it’s easy to take for granted when it exists, and to identify more problems deviating from the lack of it when is not present. We typically talk about how great cultures are innovative, open, communicative, fun, collaborative, etc. but one of the prerequisites that makes these values worthwhile is Respect, both to your coworkers and to the work itself.
R-E-S-P-E-C-T
Find out what it means to me
Without Respect, ideas are accepted mostly depending on who present them, and need to be imposed. Even when there are explicit request for ideas, they take the shape of “suggestion boxes” where no one really looks into them. So, in practice, being proactive is discouraged unless you’re in a power position.
When there is Respect, ideas can be freely exchanged without fear of not being talking seriously. They are also welcomed from any source, not only through the “chosen channels”. There can be hard scrutiny, but it will be fair, and rejections will be reasonably based in facts.
Without Respect, a “funny, relaxed atmosphere” can be easily transformed into harassment and abuse. Jokes will actually hurt. Closed groups, extremely aggressive with everyone external with them, will be formed. That can include groups outside the company, like mocking customers or partners. Some groups will be appointed as intrinsically “better” (engineers, executives…) as others (secretaries, workers…) and generate asymmetrical relationships, with one part dominating the other.
When there is Respect, jokes are played just for the laugh, and are taken up to the correct limit for everyone, as there are people with thicker skin than others. If those limits happen to be crossed, the problem will be arisen and people will sincerely apologise and correct their behaviours in the future, without external influence. Occasionally the customers or partners can be make fun of, but the quality of the delivered software will be took extremely seriously (the highest form of Respect for customers) and their requests or suggestions will be taken into account when making new features.
Without Respect within the company and the different groups, no particular measures will be enforced to protect anyone or anything. Therefore, it will be easy for someone to take advantage of that, ranging from lower the quality of the work to be a moron and degrade the working environment. Code will devolve into an unreadable mess, and technical debt will grow uncontrollably. Hiring standards will get lower, and not-that-great people will be part of the team (technically, but also in a more personal sense). Also, the expectations will be to work overtime regularly, without any contingency plans or treating it as a bad sign.
When there is Respect, the organisation truly cares about the people, and not just as an empty statement. This includes understanding when overtime is unavoidable evil and work as a team to avoid it as much as possible. And when it happens, everyone do as much as they can to make it as short and enjoyable as possible. There will be understanding when someone wants to leave because they have a genuine different interest, leaving the door open if things don’t turn out for the good. Learning and personal growth will be encouraged with actions, not only with words.
Trust, a extremely important value, can only arise if there is Respect. Without Respect, fear and uncertainty will replace real trust. Being honest needs trust and confidence in the other part, as real honesty can be, and sometimes should be, uncomfortable to hear. Formality and defensiveness take control over honest feedback and team work when respect is not present. Any long-term relationship also needs Respect to stay healthy.
What have I ever done to make you treat me so disrespectfully?
Being imperfect human beings, we cannot probably achieve perfect respectful relationships at all times. But we should try to be as respectful as possible, identifying our mistakes and the ones of the organisation, and move up towards the Respect ladder. That makes a much healthier (and happier) environment for all. We should recognise the Real Respect, as the word is often abused.
It is great to aim for having a great organisation or startup, with a thrilling culture. But, in order to get to establish a funny, exciting, learning, diverse and passionate place to work, we should lay strong foundations with Respect. Identify it, and not tolerate the lack of it.
Compendium of Wondrous Links vol II
- 60 hour work week is not a badge of honour. I talked about something similar here some time ago.
- Social Aspects of Success and Failure in Cultural Markets. Follow up about the Flappy Bird issue, and about the unpredictability of success.
- About retaining team members, which is not an aspect of companies that is not as discussed as recruiting.
- Some interesting Unix tricks and recipes, in a very simple txt format.
- Very graphic display on how conditional probability works.
- Levels of excellence. Interesting view on learning. It is fascinating how sometimes it truly seem like “a level”, a real qualitative change.
- You Are Not So Smart blog is amazing. Here is just a taste of it (The Benjamin Franklin effect), but all the articles are great. It includes the following amazing quote “We are what we pretend to be, so we must be careful about what we pretend to be” by Kurt Vonnegut
- A brilliant car insurance turkish commercial, presenting a real-file Street Fighter bonus phase
- The Pixel Density Race and Its Technical Merits. We are probably approaching the limits of what make sense in terms of pixel density.
- And two nice graphs from Twitter:
First job in a startup considered harmful
Well, at least is not ideal from my point of view…
At the moment there seems to be a lot of hype about startups. And why not? They are the places where the cool stuff happen. Filled with purpose, excitement, high stakes, fantastic teams, growth opportunities and the rare chance of maybe becoming a multibillionaire at a young age. I’ve worked in big and small companies (including startups), and I definitively prefer to work on smaller ones. You’re impact is bigger, the team works closer, way less corporate BS, etc…
But, while I think that working on a startup is exciting, and a great career move, I don’t think is a great first job. When starting a career on tech, a better place to start is an established company, at least for one or two years. Why? Simple because if you want to be a rebel, you have to know what to rebel against.
How else are are you going to know how to use a rubber chicken with a pulley in the middle?
Established companies have a lot of bureaucracy, process, rules and middle managers. They are boring, that’s for sure. But there is one thing that they have than an startup has not. A proved method of doing stuff. A running operation. It can be dysfunctional, inefficient, stupid o just crazy, but they are being able to earn money with it. While the stupid processes seems to be there with the sole purpose of annoying workers, they are there for a reason. Maybe not the best one, but it is great learning experience to navigate through them.
Also, within all that craziness there are some steps that make sense. Something that has been refined after years of experience and a lot of work and it’s there for a reason. On every department there is some one that is actually brilliant and knows everything around. These people are excellent mentors. Not only on tech, but also on “the business world” and career-wise. We tend to think when we start that everything older than 5 years is obsolete. Talking to someone that is 25 or 30 years older gives a lot of perspective. They had gone through a lot, and their experiences are very valuable.
And, obviously, because that will make feel some of the pain on what a big company is. When I was a freshman out of college, I’ll just accept things that will drive me crazy today. Once you think about that you can effectively remove the pain points knowing why, and with actual experience on them. It’s the equivalent of measuring some software to discover the bottlenecks and then concentrate on them, instead of just making wild assumptions. Without real work on the field, it’s all premature optimisation.
Moving in the opposite direction, from small company to a big one can be absolutely horrendous. It is extremely difficult to perceive an increase in bureaucracy and processes as an improvement. Even in the few cases when it is. Having facing it in advance helps accepting it.
To be able to recognise how big companies operate and what are the real reasons why you don’t want to work there is a great experience when working in a startup. Of course, a small company have its challenges. But if your aim is to improve what big companies are doing (and that should be the goal of anyone working on a startup), how do you expect to do it without knowing it beforehand?
Compendium of Wondrous Links vol I
As a way of collecting interesting reads across the Internet, I plan to keep a relatively regular posts with some articles and posts that I’ve read, mostly related to development, software and tech world in general.
Here it goes the first edition.
- Your Progress As A Programmer Is All Up To You
- Theory and practice Short and simple, but nice
- Every line of code is always documented Nice ways to use version control to our advantage when navigating through unknown code
- When random isn’t random enough or why randomness is a more complicated problem than it looks
- Interesting talk about different databases and distributed queries
- A 1986 Bill Gates interview about coding. It is interesting how some of the topics are still challenges today, but have been more refined, like team collaboration. Love this quote “We’re no longer in the days where every program is super well crafted.”
- Why indie developers go insane, about (but not limited) to all the Flappy Bird issue
- Nice graphic representation of version control history. Using airplanes!
- gn command for Vim. This is a very interesting new addition to my Vim lexicon
- Very good points about non-English speakers developers. Not sure if I totally buy it, at the end tech world is so predominantly english, that being able to use it is a huge win, but still interesting read.
- Being a noob programer at 38
Hope you enjoy it!
Wrong Side of Memphis 