I consider myself a problem solver. You might have an image of what a “problem”
is in the programming world, but I should be clear - most often than not, the
problem is inheriting a project from another programmer, or using one of
such projects as a dependency. In the extreme, you realize that you are
solving problems created by other programmers and find that you tend to dislike
the whole bunch, just because you don’t agree on the definition of problem.
In a post by Ivan Voras on TopTal, he describes his remote digital workplace.
From it, I can only understand that he is a freelancer, which didn’t grow out of start-up garage mentality. Amazon, Google and Apple started in a garage, but it was a different time. And what people seem to forget - they were working, they weren’t setting up a work environment. Today you can lease a server and set it up in minutes and start working.
I guess I have FTTH for about a decade now. A solitary modem into which a solitary optical cable brings a signal for internet at 20/20 mbit speeds. And even television, with some kind of frequency splitter. All for the cost of about 40 euros give or take.
But it’s a terribly inconvenient way to live. The thing is idle. And all the devices I have run on WiFi. Or LTE. My phone, my tablet, my laptop - none of them are connected by any kind of cable which would take advantage of this kind of setup. So what’s the point?
Let me start with a story. There was a group of friends, somewhere in the fog that was 1997. They had a common interest - computer programming. But not any kind of software, no, they wanted to see how far they could push hardware back then. They were doing the kind of stuff that today you only see in video games. They traveled to various competitions around Europe, having gotten some good placements with their entries. Real time rendering of animation, ray tracing, 3D graphics, music,… and meeting people who shared their interests.
I have been looking at a Toshiba Chromebook 2 with Full HD screen for the last few months. The $300 price tag, my dying home laptop, and the good reviews convinced me to finally take the plunge and purchase it as a laptop for home use.
If you, like myself, have a Cisco VPN at work, you might find out that you can’t connect the Chromebook to your VPN. From what our network engineer found out it’s basically just some XAUTH mismatch. If you don’t know what that is, the basic take away is - you can’t connect without having additional software, OpenConnect. But how to run it in a Chromebook?
In my many years as a software developer, this is one phrase which I have heard over and over:
"Don't optimize your software prematurely."I have no idea where the phrase came from. I know that most software is shit because people don't know any better. And generalities like this encourage people to write bad software. I will try to list a few things that I think make up a good developer culture. Invest in people, not hardware Developers should be encouraged to think about possible bottlenecks before they happen. Generally, this is called planning, or in some extreme cases, premonition. As long as people are paying attention to detail, the problems will be obvious before they happen. The thing which I see too often is that a lot of managers throw faster SSD's, more ram, faster and more CPU cores at the problems which shouldn't exist in the first place. This encourages a culture of programmers which think every problem is solvable by more hardware. You wouldn't believe how much running costs we have saved by correctly writing the software in the first place, and then additionally only tweaking the few bottlenecks that were found after the fact, mostly caused by feature creep. Share your failures If you make mistakes, learn from them. Define what you did wrong. Admit to your problems and share your failures. If anything, a developer should be comfortable admitting his failures, rather than hiding them. To quote the old adage "The first step to fixing a problem is admitting you have one." and regarding sharing your problems: "Those who cannot remember the past are condemned to repeat it." Admitting problems shows integrity, which in turn increases trust. Nobody is perfect, it is only how you handle failure that defines you as a person. I'd take the programmer who admits his failures and works on them any day of the week, because I will trust them to say what is and what isn't going well. Sharing the problems with other developers means other people can also learn from their failures. Specialize Don't be the guy who knows and does the little bit of everything. While this is fine for individuals and small teams, being specialized is better than being generally good at everything. That's my theory at least. An expert for SQL only has one problem domain the whole day. Writing SQL queries, preforming DBA tasks. His problem domain becomes his life, he knows how to set indexes and create database structures and squeeze the last bit of performance out of the SQL services. Now imagine that SQL guy having to work with JavaScript as well. Write some JavaScript, work on some SQL, write more JavaScript. The attention to detail falls by the wayside soon enough, and time is lost in the context switching between the two problem domains. A specialized developer will solve problems in his own problem domain by a factor faster and better than other developers. I have seen this many times over in projects over the last 10 years, small and large. Specialized programmers however will choke if they have to work on projects that require many skill sets from them. There are not many exceptions to this rule. Ask for help You don't need to do everything yourself. Delegate. Figure out what needs doing and what is important. Inevitably there are people around you who are better than you at something. Communicate. This section could be called team work, but I find it important to get the message to your head that you are an individual. Your skills are your own, and other people have other skills that might be better than yours. You don't need to know and do everything, and don't be afraid to ask for help when you need it. You can search and talk about things outside your company and connect with the local developer community. In conclusion... Out of context managers use the phrase "don't optimize prematurely" as another way to say "write code quickly". In practice, performance goals have to be kept in mind, with a balance between design and optimization. You will inevitably work with some bad programmers or contractors. The "shining light" at the end of this tunnel however is, that the better you are at your craft, the better people you have around you. I've seen good programmers rise out of very unconventional places. "Cream always rises to the top" - Tit Petric
