4 ms·
I think there are different ways to be a good programmer, beyond basic intelligence and diligence. In security and high-availability related environments – whe
by wvh 9y ago
I think there are different ways to be a good programmer, beyond basic intelligence and diligence.
In security and high-availability related environments – where I've spent most of my time – it is important that you validate all ins and outs, system and function returns, check if writes succeed, in short, not unlike a chess player, to be able to fit all possible moves and scenarios that could go wrong inside your head. You probably need to naturally possess a mind that is precise and can find all loopholes.
Another way is to see efficiency through layers of algorithms and realities of real-life systems. Universities focus too much on mathematical formulas in my opinion; real systems are not clean and simple like a math function with few variabes. To understand by experience where complex systems with remote databases, shared disks and network can go wrong and write code that foresees, prevents or deals with unexpected complications is an important skill that sadly enough is hard to quantify on a resume. A lot depends on experience and knowledge, but you need to have interest and curiosity to get there.
And finally, you have those programmers that can create a more-or-less working mock-up in mere hours. In my experience, those are not always the people that want to spend a year ironing out all the bugs, but it is a valuable skill to be able to adapt and churn out something fast and iterate on it. Dare I say, the Javascript mindset. You probably need to be pretty enthusiastic about new technologies and quick on your feet.
To find not only a motivated person but the right "type" for a job position is probably not an easy task, just as it is hard for a programmer to find the right job that fits your own particular strengths and way you like to work. You might be a good programmer, but end up in the wrong environment. If you are a thorough and perfectionistic person, you're probably not going to be happy in a mockup-a-day start-up.
- runeks 9y ago> Universities focus too much on mathematical formulas in my opinion; real systems are not clean and simple like a math function with few variabes. How many variables your functions consume depends on how much you split them up, although you'll of course end up with thousands of functions for a real application, if they each consume ~3 arguments. So, in other words, the limitation is to what degree your language enables you to split up your application in tiny, obviously simple fragments. Mathematical functions can describe anything. Haskell consists of mathematical functions, and is Turing-complete, and because of its purity makes it easy to split up your functions into tiny ones (or at least sufficiently small). For example, this[1] module is a Bitcoin payment channel server I'm writing in Haskell. The module describes, mostly at the type-level, three different Bitcoin networks (live, test, test-derive), and presents an interface to the Bitcoin network, which either fetches information from the Blockchain or deterministically derives test transactions. Everything can be split up into tiny pieces like this, it just takes time, as the purity prevents you from utilizing loopholes that later turn out to be unmaintainable. It forces you to understand the essence of what you're trying to describe, because otherwise you can't capture all the invariants properly without too much duplicate code. [1] https://github.com/runeksvendsen/rbpcp-handler/blob/master/src/RBPCP/Handler/Internal/Blockchain.hs https://github.com/runeksvendsen/rbpcp-handler/blob/master/s...
- wvh 9y agoI think we're talking on a different level here. I'm rather thinking about the performance from an ops perspective. If you write highly specific code that runs close to the processor, of course predictability improves. But if you write a web application, possibly running in a virtualised environment, using remote databases and other network services, good look predicting performance to the end user. Even talking about tight loops, you simply can't predict if it will go and stay in the processor cache in layered, multi-tenant situations like that. There is little correlation between theory and practice of a complex system when it comes to performance and reliability. For example, big-O notation tells you very little about the myriads of wonderful ways systems and networks can crash and burn. Disks never failed in my university classes. The more you know about the difference between a perfect theoretical system and the harsh randomness of a real one, the foresight of experience, the better a programmer you are, and this is not generally knowledge that comes from formal education. In short, to be a better programmer, you need to know the difference between the best case ideal scenario and what is actually going to happen, usually when you least expect it...