> "People who can code in biology, medicine, government, sociology, physics, history, and mathematics are respected and can do amazing things to advance those disciplines"
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.
My favorite example of this is OsiriX[1], a GPL'd medical imaging (DICOM) viewer written by a radiologist who couldn't find existing software that did what he wanted. It's now an established part of the DICOM world.
Here's just one possibility. Say you want to do genetic testing for susceptibility to a particular trait, for example heart disease. The human genome is vast, and no human could pick out significant patterns relating to heart disease even with years of experience and specialist training.
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.
"People who can code in the world of technology companies are a dime a dozen and get no respect" , I disagree with that, I think you got a lot of respect in a company that is focused on technology. But If you are working into a marketing company in the development team, then yes you will not get much respect..
I'm sure the OP would agree that a coder in a marketing company would get even less respect as you'll merely be executing their (not that technically challenging) vision.
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.
What I think he means by "if you have coding as a secret weapon" in this case would be, if you are a Marketer that can code as an extra, you will be highly valued.
I am a marketer who can code in a rudimentary manner. I've done projects on a shoestring budget that have netted companies thousands of new customers and hundreds of millions of dollars.
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.
I'm a web developer in a marketing company. What you said is partially true, especially if your management doesn't really understand development (highly likely.) However, if you are able to look at the work that comes down, and come up with better ways to do it and engage management (rather than just being a set of hands to do their bidding) you can increase your value. You will never be as valued as you would be at a tech company, but you can try.
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.
"People who can code in the world of technology companies are a dime a dozen and get no respect"
Generally in business, those people whose job title is 'programmer' or 'developer' or 'software engineer' get relatively little respect even with lots of experience. (I am 37 years old and programming since 12) Previously I thought the only way out of this is to become a 'manager', which I never really wanted to do... Recently I have discovered 'quantitative finance' which is a quite respected and interesting geek profession (with lots of math, which i like), and I am planning to transition into that in the long term. (Theoretically a relatively smooth transition is possible because there are 'quant developer' jobs out there.)
a) Is "respect" really so important to you that you are willing to sacrifice a 25 year career? Surely if the pay is good and you enjoy that's all that matters.
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.
Whatever people say about "lawyers", people tend to have a lot of respect for their lawyers. It's lawyers as an aggregate that people tend to stereotype.
Part of the respect is a better pay, which is important to me as I have small children to care about. But the main reason is that so far I enjoy learning quantitative finance.
" 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.
Being respected in that sense is extremely important. First of all, people need to pay the bills, which you can't do if your work is viewed as a commodity and you're therefore in wage competition with 22-year-olds and outsourcing shops. Second and more importantly, for the types of people who learn programming to enjoy their jobs requires a certain amount of autonomy that isn't usually granted to non-managerial workers.
"Respect" is a social construct that relies highly on social interaction. Since programming is a lonely activity it's hard to earn respect beyond peers. Not that one should really care about that much. I have found that i earned more respect when i started introducing myself as "entrepreneur" than i got when i was "programmer", even though i actually work less in general now.
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.
That is sadly true. I've been developing software for the past 6 years and have helped organizing several developer oriented events.
Now I have worked in entrepreneurship for 8 months and am currently organizing the first entrepreneurial event(Startup Weekend).
Yesterday i received an official invitation from the city council to a banquet for entrepreneurs in our city...
Programming in a commercial sense really means solving other people's problems under a set of constraints over which you have little or no control. I always get a little annoyed when people say, in an interview, that they have 10 years experience, because they started at 12. That's great and I encourage it, but it's not transferable to a commercial setting any more than playing Chess for 10 years is. In fact I would take the Chess player give the choice.
In my experience it's the programmers who can ONLY program that get little respect. The ones that can also understand other problem domains (business/people/processes) tend to get respect no matter what their job title, even in technology companies. So Zed is right - programming is most powerful as a tool to be applied to more interesting problems.
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.
I'm also 37, and have been programming a similar amount of time (15 of those years professionally). I've worked in 2 person, 10 person, 20 person, 30 person, 50 person, 300 person, and 5000 person organizations.
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.
> Wish to belong
This is a fairly hard thing for me to do, because every faction i have been part of or tried to be loyal, to have limits on what beliefs can be questioned and what are not open to be experimented with. There comes a point where i disagree and have trouble stopping myself from experimenting. So loneliness is not a problem for me. But i have a very limited/narrow interest in being important. To some extent the admiration of peers feels good, but not much.
So at this point, i find myself a little lost as to what do i want to move forward towards. Made worse, by i have trouble just enjoying when am not sure what am working towards.
UPDATE: Eeks,sorry if it's turned to a ramble.
It sounds like you're comfortable as a loner then. That gives you immense possibility, but also makes it harder to choose.
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.
Am also planning to switch to quantitative finance, though am just figuring out a sense of balance between work + learn/play time. I would call myself to be in the "early adulthood" phase and am figuring out my first love is math.
>"Theoretically a relatively smooth transition is possible because there are 'quant developer' jobs out there."
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 agree with you about IBs and large banks. We had some really interesting stuff going on to the extent we were leaders in our field. I wouldn't call CFA lightweight though, I found it hard. It was mainly memorisation of boring, boring, boring stuff. Little motivation == hard.
In some fields, given a CIO title is akin to being demoted. Nobody wants to be the head of the IT operations because the money is somewhere else (sales and marketing).
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.
"Finally, I'll say that learning to create software changes you and makes you different. Not better or worse, just different. 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."
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.
Maybe you'll find that because you can dissect their logic that they hate arguing with you.
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.
And those people usually get their way, too. Quite frustrating to deal with them, mostly when they come back to you after their way didn't work out and want you to solve it.
I think this piece keeps coming up every so many days. It's a great piece of advice, and i think most developers come to the same conclusion after a few years. I think a useful corrolary from this is "Do not reinvent the wheel all the time by changing programming styles, instead try to extend the frontiers of technology" (I 'm looking at you, web frameworks).
This. I was reading someone's blog the other day about how they were rewriting their app in node.js... whereas a few years before that, I remember that they had rewritten the app in rails... Their product could've been so much further along had they just stuck with php/.net (whatever is was originally).
Yep, and it always reminds me of how far Apple came with Objective-C. Microsoft and Google continually push new languages on us, and yet Apple developers used Objective-C for over 16 years just fine, and continue to push technology barriers with it. Apple instead chooses to improve supporting tools - XCode, etc.
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
The initial release of OS X was March 24, 2001. IIRC, ObjC was not used on MacOS 9. Unless you're talking about the creation of OS X out of NeXT (which Apple purchased in 1996), and therefore Apple employees (not just 3rd-party devs that work on the Apple platform).
Objective-C the language has existed since the 1980s. I remember reading Brad Cox's book "Object Oriented Programming, An Evolutionary Approach" in the early 1990s.
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.
The original comment was about Apple developers using it for over 16 years. You can't count the NeXT years, as NeXT developers were not Apple employees.
Let me know when you can tell a Fashion designer you hate their dress by writing on the back of some girl wearing it. Oh, and doing that without software.
Eh? Are you saying that the random hate commentary at the bottom of online articles is required for something to be art? Your comment just doesn't make sense.
When I read pieces like this, it reminds me there are many reasons for learning to code. Some learn just because the technology is interesting. This is a fine reason, but what's interesting today will not continue to be interesting tomorrow.
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.
I worked for a company where they had a student (internship) set up the LAN, among other things. He got the job done, they liked to boss him around and pretty much everyone agreed the guy was lazy and there was no way they were going to hire him, blah blah.
Truth be told, you could see he didn't like it there.
But they couldn't have been more wrong about that guy.
And I've seen this over and over again: it has nothing to do with technology.
It has everything to do with the people you work for and how big of an influence your job has on whatever it is a company is trying to sell.
It's very discouraging to a lot of people when they're in a situation like that guy was.
Fortunately, he only stayed there for like 6 - 9 months (too long, imo, but he had no choice), so when his time was up I asked him where he was going.
He was going to work for a company that offered network solutions, he figured that was a better choice than to go work for a company similar to the one he just interned for.
And he was right.
I happened to know the company and the owner, so I assured him he made the right choice.
I checked up on him a few months in and all I can say is: time to move on when you're in a situation like he was.
"Programming as an intellectual activity is the only art form that allows you to create interactive art"
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...)
Let me know when you can tell the Architect that his building needs improvement or contact a designer about their devices. Oh, and without programming.
Also a part of this problem is that many programmers are assholes. Going out to the world while thinking "im to smart for the rest of the world, tha hell with them" is just a big social failure in general. One need to be able to see things out of different perspectives, a bit more open minded. Just because a person like to do other things in life then CS-stuff, does not mean they are automatically stupid.
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
...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.
"If you're worried about getting respect, you're worried about the wrong thing".
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.
Yes. We seem to be trying so hard these days to make our organisational structures appear flat and informal (e.g. open plan office spaces, casual dress policies, "360 degree reviews" and an aversion to using job titles) that I feel it's just pushed the competition for status and respect underground. The people who've been around for a long time simply find other ways to show newcomers that they're important or that they should be listened to. Things like camping out in one of the meeting rooms "because I have a lot of import calls to make". Or wearing something just slightly smarter than everyone else. Or a kind of faux humility like ScottGu's sub-title on his blog: http://weblogs.asp.net/scottgu/. Or coming to work in their 1998 "version 1.0 shipping date" T-shirt.
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.
I think it's a question of balance, at the other end of the spectrum you can get growing startups where the initial "everyone's on a level and talks about everything" approach no longer works and has given way to a combination of multiple people competing over the same territory and the old guard finding ways to remind the noobs what the pecking order is. In that kind of situation, a little hierarchy and a few harmless ways of recognising past achievement/tenure would make for a much more harmonious work place.
> I disagree. I've met a lot of non-programmers who knew a little programming. They were more dangerous than effective.
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.
Fully agreed here. It's amazing how many people could be replaced (or freed up to do better things) by very simple shell scripts or excel macros. This is where someone who knows a little programming but understands the business process really well can be highly effective.
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”."
It's really a tragedy that the same company - Microsoft - is the origin of the only reasonably successful business-focused programming environment (VBA) and the notion that interacting with a computer through any other means than point-and-click - especially typing command and editing text files - is hard and is only for stupid geeks with bad hygiene.
Microsoft is not responsible for people hating to type commands in the command line, early computing is. In the past you were forced to type commands to get anything done and a lot of people hated it. The introduction of the GUI made things "easy" for most people.
No, they didn't invent it, and for the most part, GUIs are leaps and bounds better than CLIs.
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.
One of the greatest companies that I ever worked for trained every employee to use Access and to solution for themselves, we had a system that monitored level of usage of an access solution as well as how much revenue it was responsible for. At a certain threshold the solution was deemed business critical and the access solution was used as a prototype for the developers to implement on a more robust solution. It was like working requirements and the whole thing ran very smoothly, needless to say it fundamentally changed my view of stakeholders solutioning for themselves. I also started to see the issue as a management problem and not a technical one, with the proper processes in place, people are empowered.
Sure so for the load monitoring they had a set of tools that where required to generate a new access solution, what this did was two things it set up logging and it would link the access front end to a Oracle backend, so they where really solutioning their data in a centralized DB as opposed to the Access database, but for the most part the users did not know or care.
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.
When I joined I spent a lot of time asking people what they did, making mind maps, and finding lots of patterns. I quickly realized that there was a lot of repetition, and that in theory it should be possible to automate, though I had no idea how. So I hit the books, learning everything I could about SAS (the main repeated tasks involved reporting/analytics) and Windows Powershell. Eventually I figured out how to automate it all, and did so. This freed up time for a lot of people, let the company hire less, allowed them to meet government deadlines that would have brought the wrath of god upon them if they failed, cancel a $1.2MM consulting project that would have taken 2 years and accomplished half of what I did, made it massively faster to create new reports, drastically reduced our error rates...
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.
"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."
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.
Hacker News implicitly asked him, by having a comment box and a community that generally rewards good comments about linked articles with karma and accolades. If you don't want to change your book based on one person's feedback, that's your right. But edw519's request was reasonable. I found his request more rhetorical than an actual request of you, anyway.
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.
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.
Edw's comment aside, I can understand being bored with programming. After you learn your way around a dozen or so different platforms, if you're not getting bored you might want to check to see if you don't have a bit of Asperger's.
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.
When I was 21, I thought the fun part was learning new technologies and the hard, frustrating, somewhat boring part was writing the code. (I also only knew C++ and Java, so I thought the accidental complexity of these languages was an intrinsic fixture of programming.) Learning Python, then Ocaml, then Lisp, was a lot of fun. (The REPL makes a huge difference in the experience of programming. It makes the code real rather than some hazy gobbledegook.) It was even better to start using these languages for real-world problems.
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.
By the way, the fun part is learning the technology. The hard part is working with people -- 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...
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.
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.
The point is that different personality types enjoy different aspects of programming. For some people the technology itself is the fun part. For some its what you can accomplish with it. There is no right or wrong here.
Yes, exactly. I think it's overall too easy to call someone else's use of spare time "trivial" because we don't understand why it could be useful for them, or to other people. We're all limited by our skills and interests. If only we could all be world-savers doing work of great impact and help to every person on earth in our free time...
"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."
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 :)
I think a large part of it comes down to why different people like programming. I learned to program when trying to figure out why computers work. I learned to work on cars when trying to figure out how they work. I like building things and I like fixing broken things. Programming happens to be chock full of both, pays well, allows more time to think and analyze the problem and getting paid for it doesn't ruin the enjoyment (for me). I could make more doing something else and I could make more working at companies where I'm not building things, but they aren't what I love doing. Life is too short do not do something you love, it's just a matter of finding something you love to do that you can get paid for.
This parallels much of the photography community, there are people who know every technical aspect and could talk for days about what f-stop/shutter speed to use in certain circumstances etc.. And then there are people who go out and take beautiful photos of beautiful things.
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.
"People who can code in the world of technology companies are a dime a dozen and get no respect. People who can code in biology, medicine, government, sociology, physics, history, and mathematics are respected and can do amazing things to advance those disciplines."
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.
With a degree in biology, even with no PhD, it's still vastly useful when paired with programming skills. You have a good high-level overview of the problems in the industry, and that's an important first step.
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.
In the corporate world domain knowledge is more important for developers than technical knowledge. The complexity of real-wold domains (e.g. insurances, banking, ...) is amazing. For an experienced developer programming is the easy part of his job.
You may find that people treat you harshly because you can create software, maybe using words like "nerd". Maybe you will 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.
To this I have one just piece of advice: they can go to hell.
:D It was worth it for that alone.
Which programming language you learn and use doesn't matter?
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.
I disagree with the idea that a language changes how you think. I think a more accurate statement is:
"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.
Hmmm.. the "way to think" doesn't change as that would be like changing the way human brain works. Still some programming languages allows you to think more abstractly than others. For ex: You see a problem and in few mins you come up with an abstract solution because the language you use provide certain abstractions to help you solve problems. It is interesting discussion though and in my free time I do try to find about how human brain thinks :)
I'm also pretty old, relatively speaking, but I think of myself as young programmer because I started somewhat later in life. Early in my career I made the mistake (for me) of going into software testing and I found myself pretty bored and unmotivated. But now that I'm a dev, I've found that my passion and dedication to the craft has only grown over time. All that stops me from coding all night when I get home from work are the physical barriers (hands/back).
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.
The meta-topic is about disillusionment, which in this profession comes from having to learn new libraries and knowledge that you know will soon become obsolete. Reduce the risk by focusing on learning what interests you (language & industry), and accept only interesting work if possible (or create your own fascinating projects, if you're the entrepreneurial type) -- or work as a contractor, where you pick your projects, focusing on your favorite language.
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.
Actually, learning all the cool new stuff that comes out is what I like the most about programming. I love taking apart new stuff, watching communities rise and fall, and dissecting the philosophies that come out of it all.
> 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.
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.
1) No I could actually write the same thing with the same quality in most any language I know, baring a few esoteric ones like brainfuck. One language may take me longer than others, but the error rate would not be higher or lower usually.
123 comments
[ 4.0 ms ] story [ 178 ms ] threadTrue. 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.
[1] http://www.osirix-viewer.com/Snapshots.html
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.
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's why Bezos is my hero.
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...
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.)
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.
- Even if am not the quickest/best at it.
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).
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.
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'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.
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.
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.
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.
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...)
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!)
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'...
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.
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.
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'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.
> "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.
http://edweissman.com/53640595
that's kind of fun
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.
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.
If it weren't for the last 3 paragraphs, I'd agree completely. But seriously- who makes fun of developers anymore?
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
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.
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 :)
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.
Not necessarily true. :)
Awesome. Well, I am a classical violinist, and I will use programming to aid me -- now with confidence!
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.
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.
QFT
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.
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.
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.
At your best you can become antibodies in the global cultural organism.