Advice From An Old Programmer
learnpythonthehardway.org
learnpythonthehardway.org
But he nails it when he points out that all of this programming talk is bullshit. It's just stuff to chat mindlessly about while you're not helping people. Programming is making computers help people. Never forget that. The more you focus on the computers part, the unhappier you are going to be.
I will extend my analogy. If after the 50th article you read on HN about some upcoming technology you haven't figured out that something is wrong with your focus you should seek help. If you want theory, computer science is a great field to study. For the vast majority of us, it is not an end to itself.
It's all very easy to get good at critiquing Judy arrays and suck at making something people want. You can carry on like this for the rest of your life. Don't do that. You provide a bridge to the future for millions of people. Please, the rest of us need your help.
The point is Photography is not about equipment "I can't take that photo without this lens" it's about photos you can take.
Programming is not about Languages and Code structure it's about making something useful using the knowledge you have (Twitter could have been made with PHP or Python or any number of other languages, it still would have been "Twitter") Heck look at PG and Viaweb, none of the users cared that it was made with Clisp just that it did what they needed it to do.
I'm 28 now and I find the writing of code to be the fun part, because I'm now good at it and know better technologies than C++ and Java. I get into "the zone" and before I know it, 4 hours have passed. Unfortunately, that's not the reality of industrial software engineering where, if you're lucky, 25% of your time might be spent writing code. Learning new platforms (often with so many of them that I can only learn enough to glue them together) is often boring. It's fun to learn new technologies when there's something genuinely new in them, but I'm sick of having to learn new and often less useful ways of doing old things.
I would probably also like re-arranging chairs at a charity function. Or solving mathematical puzzles in books. I also love instrument flying, which is like real-time fluid dynamics where you die if you screw it up.
But I've come to understand that these are just properties of the types of people who grok computers -- detail-oriented, able to spend many hours in the zone, and in love with complexity. At some point, the "benefits" from this personality type become drawbacks. There are a lot of guys spending thousands of hours on code in their spare time that might help 3 people -- who are also programmers. I'm not saying this is a bad choice. It just seems to me like we programmers as a whole like trivial things and can spend most of our time on them as long as they tickle our analytic bone. Continuing my flying example, there have been cases of people flying airplanes into the sides of mountains in perfectly good weather while they were fiddling around with the flight computer. Many of us are doing the same thing -- only in very slow motion.
By the way, the fun part is learning the technology. The hard part is working with people to make something they want -- which is why it's about a million times more important.
That's very interesting, and indeed seems to mark a certain personality type. Most people would see that exactly the other way around, that working with people is fun and easy, but the technical stuff is hard and extremely frustrating.
It depends completely on your skill and what you're used to. Almost all people tend to think their own area of expertise is easier compared to others and don't understand why other people don't get it like they do (which has a simple answer: years of experience).
There are a lot of guys spending thousands of hours on code in their spare time that might help 3 people -- who are also programmers
Nah, helping 3 people in your spare time is more than helping no one. You're right, if your goal is to help as many people as possible, programming isn't the right time sink. Better to sign up for some volunteer job. On the other hand, you could also be reading a book, playing a game or watching TV and helping exactly no one :)
Edit: and don't forget many non-programmers also spend their spare time on very trivial stuff. The problem is not exactly limited to technical people...
Learning technology is fun when it adds something new. For example, if you know functional programming, then Gang-of-Four "design patterns" are completely useless cruft and not especially interesting to learn. It's painful to learn that sort of stuff when it's less powerful than what you already have and would be able to use in a better environment.
"Working with people" can be fun, to a point. It's enjoyable when there's no power relationship, or a symmetric one. What's difficult is the context-switch from programming to interpersonal communication. It takes some time.
This explains why some of us (Me) can spend so much time playing computer RPG's, when we could get the same progression and more real-world benefit by planting a garden. I guess I'm also too impatient for that :)
Not necessarily true. :)
That is the best thing in his advice column.
It's hard to pull off though. I started programming at 5 and am at a skill level comparable to this poster, but I studied biology in college with an eye to doing exactly this sort of thing. Then I discovered that bio is a Ph.D's only club and that you cannot get any kind of job in the industry if you don't at least have a Masters'. I didn't want to do this for various reasons (money, not liking school), so I found myself back in IT/programming where the pay was 3X higher than what I could get in the bio world with a BS only.
But it seems like in today's competitive market (especially when it comes to doing a startup), you need 2 degrees. Computer Science is not enough. It's just a set of tools but if you don't have a domain where you can apply those tools, it's useless. It's like knowing how to write. Great! if you don't got anything interesting to say, or expertise in a specific area, it's almost useless. Of course I guess you can write about writing, which is analogous to writing developer tools.
Programming is not everything in life as many would like to think. Handling different kinds of people in different kinds environments for example is much, much harder then learning how to code.
Connecting this all together has made up a history of non sympathetic people doing "the coding stuff" at the office where everyone else just stop caring about these guys cause you can't really talk to them. Now im just talking about the stereotype thats has been biting us in the ass for ages. Portrayed in media etc etc
This has been covered well in the beginning of the social network where Mark get lectured up by his girlfriend at the bar....
So really from experience, a good way out of this is not going to management, but just to "listen" to other people and open up your mind a bit...
/coder since age of 13, 29 years now, startup, the whole 9 yards
"im too tough for the rest of the world, tha hell with them"
Because being smart and confident is just uppity, but being tough and confident is baller yo.
It's being arrogant and snarky that upsets people.
(I'm not aiming this comment at anyone btw!)
What I've discovered is this: In larger organizations, you get respect by being the "answer" guy. If everyone's coming to you for advice, you become more important.
In small organizations, you get respect for being the hero, who waves his magic wand and fixes things after everything goes to shit. This is easy to do since most of the operations are pretty basic and cowboy to begin with.
The biggest key to respect (in mid-to-large organizations) is playing the political game. The more your name is on peoples' lips, the more important you'll appear to be.
But the question is: WHY do you want it? If it's for the money, you can get much more money with less effort freelancing or consulting. If it's for security, you could also get that by digging yourself so deeply into an essential project that nobody can get you out. If it's for the admiration of your peers, just remember that it also sparks envy, and separates you from them emotionally. If you wish to belong, you're far better off choosing a faction to ally yourself with, and remaining loyal. Elevation is a loner's game.
My advice: Just pick something interesting and go with it. If it doesn't work out, pick something else. Fear of failure is worst in people who haven't failed yet, and that fear will impede you far more than actual failure ever could (I've had a few spectacular failures in my lifetime, to the point of being reduced to the clothes on my back, and each failure made me more fearless).
You don't need the respect of others when you're making your own path.
Quant-Developer is a weighted sum of q% quant and d% developer. Ideally you'd like q to be high and d to be small. What happens in practice is that many companies will hire a quant developer, throw 90% of d at you and keep you enticed with some 10% q. This is rather sad, but I have seen this happen to more than half of the graduating class of 2011. Perhaps 5% of my classmates are doing 100% q. Another 20%, including myself, are remarkably lucky to be doing 80%q , 20%d. But the rest of my classmates are stuck with 80%d 20%q, and even the q is watered down cookbook solutions. And this is the case with University of Chicago graduates, so you can imagine what goes on with grads of non-top-10 quant schools. There are companies in the chicago area (morningstar, for eg., and even much of cme) which advertise for quant developers but give you 99%d, 1%q ! What they really want is an sql guy who maintains the securities database and writes stored procedures, but they will go ahead and call you "quant developer" anyways. Its a rather shady practice imo. Sadly, the worst offenders are startups in finance. I spoke to one who asked me a ton of interesting quanty questions straight out of Mark Joshi...but when it came to the actual job I'd be doing, the CTO says (actual quote) "you don't need anything more than mean and variance, we are all generalists here". Then why do you want a guy with a math masters and a cs masters and a quant masters...just hire a high school student.
Your best bet is to stick with IBs & large banks. They have tons of really interesting ( and really hard ) math problems to work on, they aren't going away anytime soon,and they will pick up the tab for your math phd costs ( or lightweight garbage like series 7 and cfa, if pde ain't your thing).
I did this a few years ago and love it.
Things you should know depending on what you're doing: Math/Finance - statistics, know stats inside and out. - differential calc and finite difference methods - Black Scholes,
Programming - the R langugage - vba, if you don't know R really well then vba can be useful for modelling. VBA is approachable enough that every trader uses it and when they move shops they take their vba models with them. - C++ or C, it's still used very widely and often is the language that interviews are conducted on. - TCP/IP performance. - linux kernel tweeks for performance.
Currently I am reading these books:
Mark Joshi: The Concepts and Practice of Mathematical Finance
Daniel Duffy: Introduction to C++ for Financial Engineers (I already know C++, but I read this because of the finance related stuff.)
b) By switching professions to a more "respected/cool" one do you not think you're just contributing to the problem of programmers not being taken seriously?
By using "cool", I get the impression that you're thinking more about respect from people outside work, rather than those you are working with. I think the article was talking about respect from the people you work with and work under, in the sense that if you are not respected, then you likely won't get paid what you are worth. From the point of view, point (a) is a contradiction - if you are not respected by the company you work for, the pay won't be good.
Exhibit: The "starving artist" vs the "slimeball lawyer".
" contributing to the problem of programmers not being taken seriously" I don't know. Maybe switching professions is an extreme thing, but gaining some knowledge in a specific domain (other than programming) is a good advice to every programmer.
As for working in other fields, from my experience in a biology lab, yes, you may earn "God-like" status sometimes, that is, become the last resort for everyone, but truth-be-told, sometimes you find yourself doing boilerplate work by just implementing some algorithm and nothing too exciting.
Yesterday i received an official invitation from the city council to a banquet for entrepreneurs in our city...
Some people argue that IT provides efficiency and in some cases increase revenues as well. The hard cold truth is this:
1) It's hard to measure $$$ from IT projects
2) It becomes internal politics: it shifts the balance and nobody wants IT to have more power.
- Even if am not the quickest/best at it.
True. I have a theoretical physics friend who's now applying a ton of machine-learning techniques to biophysics stuff (in an academic setting).
I've no idea exactly what he's doing other than he's always snowed under and people keep coming back to him for more.
However, this is precisely the task at which machine learning algorithms excel. You split your data into two sets: people who suffered heart disease by time X in their lives, and people who didn't. You then apply a machine learning technique (some kind of classifier - maybe a logistic regression, support vector machine or a decision tree) to the data set, and it picks out features (i.e. particular gene sequences) which are most strongly predictive of heart disease. If you've chosen the right technique, you can not only predict a binary yes/no response, but you can predict a probability between 0% and 100%.
Now you can do genetic testing on an individual who hasn't suffered heart disease yet - with a suitable portion of their genome, you feed it into your classifier and it spits out the probability of them developing heart disease by stage X in their life.
Of course, the inputs don't have to be genomes (and quite commonly aren't). You might consider someone's age, calorie intake, level of exercise, social class etc. all as valid inputs to this kind of algorithm.
Some have learned to code because they want a steady job. This is an ok reason, but being an accountant, plumber, carpenter, or "running a fast food joint" has the same benefits.
The best reason to learn to code, and the reason I did, is because your head is full of..... stuff. Stuff that is always there, choking out simple thoughts like "I'm hungry" or "I'm tired". And the supply of stuff never runs dry, it constantly increases and overwhelms other thought and builds up immense pressure on the sides of your cranium until your head feels like it'll burst.
And the only way to relieve the pressure is to turn that stuff into code.
That's why you should be a programmer.
Instead, I like the letter from _why in this post: http://delicious.com/redirect?url=http%3A//www.smashingmagaz...
It goes:
I do not write tests for my code. I do not write very many comments. I change styles very frequently. And most of all, I shun the predominant styles of coding, because that would go against the very essence of experimentation. In short: all I do is muck around.
So, my way of measuring a great programmer is different from some prevailing thought on the subject. I would like to hear what Matz would say about this. You should ask him, seriously.
I admire programmers who take risks. They aren’t afraid to write dangerous or “crappy” code. If you worry too much about being clean and tidy, you can’t push the boundaries (I don’t think!). I also admire programmers who refuse to stick with one idea about the “way the world is.” These programmers ignore protocol and procedure. I really like Autrijus Tang because he embraces all languages and all procedures. There is no wrong way in his world.
Anyway, you say you want to become better. I mean that’s really all you need. You feel driven, so stick with it. I would also start writing short scripts to share with people on the Web. Little Ruby scripts or Rails programs or MouseHole scripts to show off. Twenty lines here and there, and soon people will be beating you up and you’ll be scrambling to build on those scripts and figure out your style and newer innovations and so on.
— _why
This is very true, unfortunately being a programmer requires dedication, non-stop learning to keep up. And this can lead to a very lonely life in a way that you don't socialize too much by favoring what we love to do. If you live with a tech-oriented city you should be fine, but for the rest of us it sucks a little, knowing that most of your friend/relatives don't understand what you do, and why do we spent so much time in front of a screen.
I've been programming for a very long time.
Me too.
So long that it's incredibly boring to me.
Actually, it's more interesting to me than ever.
...I knew about 20 programming languages and could learn new ones in about a day to a week depending on how weird they were.
I have a cursory knowledge of quite a few myself. But I know one really, really well.
Eventually though this just became boring and couldn't hold my interest anymore.
That may be because you're too focused inwardly and not toward your users.
This doesn't mean I think programming is boring, or that you will think it's boring, only that I find it uninteresting at this point in my journey.
Not me, and I'll tell you why shortly...
What I discovered after this journey of learning is that it's not the languages that matter but what you do with them.
Yes!
Actually, I always knew that, but I'd get distracted by the languages and forget it periodically. Now I never forget it, and neither should you.
Yes fellow programmers, this is a trap! Even after 33 years of building stuff for my users, I'll have a day when I realize that it's already dinner time and I haven't done a damn productive thing all day long. Just played around for the fun of it. (This is not a bad idea every once in a while, just as long as you know its a trap, and eventually you have to get back to work. Do this for months and you can really lose your way.)
Which programming language you learn and use doesn't matter. Do not get sucked into the religion surrounding programming languages as that will only blind you to their true purpose of being your tool for doing interesting things.
Yes. I've made about 4,500 Hacker News comments, but I don't think I've ever participated in a language war. Fortunately, I instinctively knew that this was pretty much a waste of time for me.
Programming as an intellectual activity is the only art form that allows you to create interactive art. You can create projects that other people can play with, and you can talk to them indirectly. No other art form is quite this interactive. Movies flow to the audience in one direction. Paintings do not move. Code goes both ways.
What about stand-up comedy? By definition, the audience is part of the act. Anyone can tell jokes to their cats, but killing a room is an entirely different story. (I found this out the hard way.)
Oddly, with the users I've had lately, I often forget whether I'm doing comedy or programming. I have to check to see if I'm sitting or standing to be able to tell the difference.
Programming as a profession is only moderately interesting.
Take out the words "as a profession" and re-read that sentence. It shouldn't make any difference. If you love programming, you can easily love it as a profession (in the right conditions, of course). If you don't love programming, do the world a favor and do something else as a profession.
It can be a good job, but you could make about the same money and be happier running a fast food joint.
Money really shouldn't have anything to do with it. You can earn a living many different ways. Do what you love.
You're much better off using code as your secret weapon in another profession.
I disagree. I've met a lot of non-programmers who knew a little programming. They were more dangerous than effective.
People who can code in the world of technology companies are a dime a dozen and get no respect.
This was a nice post from OP until this sentence. This is just stupid. There may be lots of mediocre and poor practioners in any vocation, but good programmers and not a dime a dozen. Also, respect is relative. If you're worried about getting respect, you're worried about the wrong thing.
People who can code in biology, medicine, government, sociology, physics, history, and mathematics are respected and can do amazing things to advance those disciplines.
People have often asked me how I've used my programming skill to help the world. I always answer immediately, "With everything I've ever done." Sure, the disciplines OP mentions are sexy, cool, and important, but so is manufacturing stuff, distributing it, accounting for the money exchanged, and a million other "boring" things. Programming to keep the world working is just as important as all that sexy stuff too. (Maybe even more important, what were all those "sexy programmers" doing for food, shelter, and essentials when they were busy changing the world? You better believe that a "boring programmer" built something to help bring those things to them.)
Of course, all of this advice is pointless.
Not really. Even though I've disagree with OP on a lot of stuff, his advice is not pointless. There's something to be learned from everyone else, especially those with lots of experience.
If you liked learning to write software with this book, you should try to use it to improve your life any way you can. Go out and explore this weird wonderful new intellectual pursuit that barely anyone in the last 50 years has been able to explore. Might as well enjoy it while you can.
Great advice. I did it and I'm so glad I did. Many others should, too.
Finally, I'll say that learning to create software changes you and makes you different. Not better or worse, just different.
This is true of just about anything. And most definitely true of programming. I can't imagine what my life would have been like otherwise. (In another century, I probably would have been a cook or something. I probably would have been happy, but I'm so glad things worked out the way they did.)
You may find that people treat you harshly because you can create software, maybe using words like "nerd". Maybe you'll find that because you can dissect their logic that they hate arguing with you. You may even find that simply knowing how a computer works makes you annoying and weird to them.
Another hard lesson: others' opinions of you should not matter. If it does, slow down and think about this again. You should be focused on your work and your users. Don't worry about the naysayers.
To this I have just one piece of advice: they can go to hell.
My feelings exactly, but I'd like to think I'd use different words. Be nice.
The world needs more weird people who know how things work and who love to figure it all out. When they treat you like this, just remember that this is your journey, not theirs. Being different is not a crime, and people who tell you it is are just jealous that you've picked up a skill they never in their wildest dreams could acquire.
It took me a long time to realize that I was an "outlier". Once I understood that, lot of other things came into perspective. That's probably true for lots of other programmers, too.
You can code. They cannot. That is pretty damn cool.
Please remove the sentence "They cannot." That's bad attitude and doesn't matter. The resulting paragraph, "You can code. That is pretty damn cool." pretty much sums up exactly how I've always felt about it. Thank you, OP!
I'm sure you're well aware of this, but there's a ton of opportunity for even very simple programming to help in cases where people have never thought of programming as a possible solution. (This is how I contributed roughly $3MM of value to one company as a kid who barely knew how to program). On the other hand, it takes a lot more sophistication (I assume, don't have first-hand experience) to add value to a place that already recognizes the value of programming and automates their work.
The danger, in my view, is that these first simple solutions tend to have more and more bolted on to them and over the years maintaining them is more time consuming than the job they were designed to replace. This is when you hire a good programmer or two to fix things.
The trick is figuring out when to pull the plug on the prototype and make things good. I'm reminded of this quote from Mike Lesk about the early days at Bell Labs: "He wouldn’t issue long specifications; he’d lash together some combination of shell scripts and awk code that did roughly what was needed, tell the customers to send him some clerks for a few days, and then have the customers come in and look at their clerks using the prototype and tell him whether or not they liked it. If they did, he would say “you can have it industrial strength so-many-months from now at such-and-such cost”."
What I'm opposing is the notion that commands and text files are something to be scared of and shun, when there's nothing so hard in it that most regular office workers couldn't pick up the basics on a three day course. And Microsoft pushed that agenda very hard.
I don't remember the exact load volume but once the logging hit a specific load volume that was when they app would be sent to development for an enterprise solution. monitoring the load happens via tracking the users that connected to the oracle instance and the application id that they where connecting with, also the amount of time used was tracked. Once the app passed the load tripwire we would look at the functionality of the app, turn each discreet piece of functionality into a service on our ESB and wire the access UI to the services, also views would be created in the DB to isolate the data structure that the users created away from the services being created. from here we delivered 1.0, which is basically the same app but now the all of the functionality is delivered via services and available to the wider enterprise, what would happen after this is that the developers would start to refine the data structure and clean it up, refining out duplicate data constructs and utilizing existing functionality where available. As well, a web UI would be developed an eventually the whole solution would be delivered via web technologies.
Now as for the revenue tripwire that was more of a mix of accounting and other variables they measured the amount of people that used the system to the revenue it generated, and based on a formula they would deem it critical, then same process would take place. If a system tracked the revenue that it generated, which most did, we would simply wire their Access solution to the revenue reporting service on the ESB and it would be automated, for systems that did not track their revenue, we would either try to develop a way in solution to track it, or the group would be responsible for reporting it. IF it was a pure cost center, they generally waited for the load tripwire.
Care to tell this story?
So basically, the key was that I really put in the effort to learn the business processes and politics, and just assumed that it would be somehow possible to automate all this stuff without really knowing how.
I don't agree with this. I agree that if you're worried about getting popularity, then you're worried about the wrong thing. Respect is important, but only from the right people.
If you want something for which popularity is the currency, by all means feel free to pursue it.
It only becomes a problem when people pursue any kind of currency just for the sake of having it, be it money, popularity or even respect.
I've recently starting to think that people have a fundamental need for hierarchy and what you might call "respect structures" and that if you deny them the job titles and corner offices then they just find other ways of projecting their status. In a way, I'd prefer the overt methods - so long as there's a route to getting there myself someday.
I just never understood the purpose. Humans are not inelastic beings who are a fixed cog in the wheel. I guess my official title is developer, but I spend just as much time in UX/design and IT roles, not to mention managing people doing the same.
And that is just at the place of my primary source of income. I work in other fields, completely unrelated to software, on the side. Out of context of my entire employment picture, developer really makes no sense as a title.
Nobody asked you.
FWIW, I felt the same, reaching the end of your post. To me, edw519's version says "I value being good", while your version says "I value being better than the others". The latter is a bit sad, as it means the value increases when the others get worse.
http://edweissman.com/53640595
that's kind of fun
Responding line by line like this is tedious for the reader, petty and plain unfair to the author. It's not a dialog - yet you're arguing it like one.
> "That may be because you're too focused inwardly and not toward your users."
Well, that was his point... it became boring because he didn't focus on what he was producing, and how it was going to be used. He became preoccupied with the technology.
On the other hand sometimes you have to take a step backward to take 2 steps forward. Sometimes thats a project rewrite, sometimes its a new programming style, new code layout, a new IDE, or a new programming language. A language is just a tool, and picking up a new one shouldn't be hard. Its natural that we tend to migrate to simpler and more productive tools over time.
> Apple developers used Objective-C for over 16
> years just fine
NeXT dates back to the late 1980s so if you're counting that, Objective-C has been used on the OS X lineage for over 20 years.
Kinetic sculptures? Fashion? Hell, go to a science museum and you'll find endless halls of interactive art, little of which involves programming.
If on the other hand you're in an industry where your skills as a coder enable those around you to do new things they otherwise would not be able to do, you'll be revered for that.
I think it is hard to argue with that.
What helps is that even if I can't code the entire project, I do know how to properly source and manage people who do. I have enough of an understanding to respectfully manage all the business and technical partners in a marketing project -- and help them work together in a way that produced a better sum of the parts.
That said, there are a number of small development companies that focus on marketing. Meaning, they are small developer run companies that take on contract code work for marketing firms (mobile apps, HTML5, etc.) and they are by default developer friendly. If you're a good dev being beaten down by management in a marketing firm, then either find one of these companies or go start your own.
That, is a dangerously double-edged wording. I see two ways of interpreting this, which are almost opposite.
(1) "Languages don't matter, in the sense that whichever you chose doesn't change the end result." Which is flatly, provably false. Different languages have different strengths and weaknesses, which makes them suited for different sets of problems. Use the wrong tool for your particular job, and you will find that your program took too long to write, or has too many errors, or is too slow to execute. Just thinking about C, Python, video encoding, and quick sysadmin work should make it obvious to about anyone here.
(2) "Languages don't matter, in the sense that they are a mean, not the end." Which is true for exactly the same reason the first interpretation is false: what should control your choice of language is your end goal. Personal preferences only matter to the extent you expect to have more fun. Given that your choice of language will change the end result, you'd be wise not to give it too much weight.
I think the author meant the second interpretation. The key words are "their true purpose [is] being your tool for doing interesting things.". A tool is only good to the extent it serves its purpose. For any given purpose, some tools are better suited than others. If no such tool suit some purpose of yours, consider crafting a custom one. In this regard, programming languages are no different.
2) This is more what I'm saying.
Don't let yourself become a cog in the machine, learning one company's proprietary library after another; to me, this is what leads to programmer burnout.
One of the challenges of a programmer (among other professions) is leading a balanced life; do not let your work define you too strongly.
Exactly. So many students and young people see programming as an end, rather than a means. They might take a class in Java or Python or somethign, hoping to learn how to write code. What needs to be impressed on people is that you don't write code to write code, you write code as part of creating an online network connecting a billion people around the world or write code to create an immersive world that tells a unique story every time someone enters it. Despite the rise of DIY blogs and webpages, people still talk about programming as if they were an artist talking about learning how to paint in order to use a paintbrush.
Last time I went to a startup meetup the people who could code were a very small minority, and they were always surrounded by others trying to poach them for their startups.
I'm glad I don't need to argue with "them" in my current position, but I've seen this effect a lot: the most manipulative people in a company are against any logical processes.
But, I know that certain languages are closer to how I want to think & how I want to be able to solve problems while other languages inhibit that or restrict the ways I think about & am able to express problems.
I only have about a half dozen years of professional experience so perhaps I am simply naive here.
There are religious wars between various languages, as I'm sure you're aware, and the driving force between a lot of the arguments is that the tool of choice is more important than solving the problem. If only they focused more on problem solutions rather than saying that Perl has too many sigils or Java is full of silly factory patterns, they'd be able to agree that Perl is useful for many things and Java is useful in many situations.
That's why Bezos is my hero.
Well, except for architecture. And industrial design. And pretty much most art that requires someone to interpret it (it depends on who you think you are making your art for - the person interpreting it, or the person watching the interpretation...)
"What I discovered after this journey of learning is that it's not the languages that matter but what you do with them."
For those developers who have only discovered the nirvana with one, or two languages, and love their rails, djangos, closures to death, just know that if one exists, there's always the possibility that there's more.
Just because you aren't aware of them doesn't mean it doesn't exist. Get building. Customers simply don't care what you code in, and very few languages give an overall edge to developing, most languages have very capable frameworks that all have their pros and cons that even out.
The question is, can developers stop foaming at the mouth and seeing the world just one way? Seems a little fanatical.
At least, kind of explain, maybe why. I don't think there's anything inflammatory here.
Thanks!
Calling insecure lashing out towards others though, all, day, long. :)
Well, that and my girlfriend. So my advice is that if you want to stay in it for the long haul, play a long game: be passionate and consumed with what you're doing but don't burn out. Have friends, hobbies, and a life outside of work.
QFT
Or to make the point that computer programming is such a powerfull tool that it's a shame to see that a lot of competent programmers are "just programmers" who think of code as an end to itself. Higher levels of manipulation and appreciation are available. Like a car mechanic, stuck with the beauty of the engine and the physics involved, but not the freedom and happiness and excitement of the car runing .
Really ?? It doesn't matter for most people because they only know C/C++/C#/Java/JavaScript/Python and other similar language as they all provide same kind of "thinking technique" and you have been programming using same techniques your whole life.
Try to learn languages like Lisp and Haskell and over a period of time they will change the way you think about programming and if something can change the way you think about solving problem, it does matter.
"A programming language teaches you to think like the language's creator(s)."
If you look at it from that more anthropological lens, then you start to see how you're not necessarily learning new ways of thinking, you're learning something more like a new language around a group of people who think similar.
Once you understand that you start to see that none of these are any better or worse than the others, and thinking like you learned some secret weapon at the Church of Haskell will really just prevent you from exploring other cultures.
If it weren't for the last 3 paragraphs, I'd agree completely. But seriously- who makes fun of developers anymore?
I will have to let the car designers know that. And the great chefs of the world. And probably dozens of other artists.
I guess it just wouldn't be a Zed post without a little light trolling.
At your best you can become antibodies in the global cultural organism.
In that sense programming is very much like the visual arts.
For what it's worth, I've been visual artist for around 40 years and a programmer for around 35.