The Little Printf
ferd.ca
ferd.ca
IMO...
This isn't universal. HN is one of the places where it is the worst. I probably wouldn't be fighting with Go right now if it weren't for HN; I'd probably be using Java. Staying up to date isn't really as important as it appears. There are people having successful careers with COBOL right now, and while that may not be where you want to go, switching between JS frameworks does not sound any better. And you can basically ignore the JS frameworks. They don't matter.
Because of HN I switched from TextMate to Sublime Text to Emacs to Vim. What did I get out of it? Not a thing. Maybe I can type a little faster when I am in vim. But mostly I just get annoyed when the rest of the OS doesn't support the shortcuts that I am now used to. I switched from Mac to Linux to Mac. I got nothing out of it, except that now I get more annoyed when I can't do something on my Mac that I was able to do on Linux. Don't do what I did.
I think it's completely possible to be a developer without all this, as long as you can recognize when you are wasting your time.
I try. I don't think going from a GUI editor to Emacs was a complete waste of my time and I still like it a lot BUT whenever you make that kind of switch you gotta stay out of the "this is the best thing ever" mentality. Instead of seeing $EDITOR as the Holy Grail that cannot be eclipsed by anything (which is false) I see it as my favorite tool in a toolbox. I like it but I also recognize it's just one of many tools and it's not always the one I should use and getting frustrated at the differences is pointless.
That last bit took a while for me to realize. I think what helped was seeing other people code without my favorite editor with an IDE or something. Watching Notch coding an FPS using an IDE caused quite a few of us in the HN thread that followed to just kinda take a step back.
I'm still relatively new to programming so hey thanks for the advice.
If you look at most of the great computer scientists and system architects, they all have very unconventional and personalized setups which are completely far off the grain.
Whether you're a developer, a medical practitioner, a lawyer, an accountant, in real estate, a mechanic, a civil engineer, a teacher, a politician, whatever you have... to be a good professional, you need to keep up-to-date. This doesn't mean latching onto the bleeding edge, but it does mean learning things and occasionally trying new tools or methods.
Unfortunately, you're a few years too late... I switched from TextWrangler to vim to TextMate to atom to emacs to vim. Totally pointless and stupid (of me) in retrospect. Same thing again with web. I'm finally learning to ignore the shiny but it seems like everyone I see/meet (both online and in person) are only interested in the backwards-incompatible new release of Express 17.0 for NodeJS, now with ES7 features.
Thanks for your response. Looking back and moving forward, I guess.
I like the keybinding conventions (all starting with SPC, hence the name).
1. starts up fast - I used emacsclient but that got to be sort of a headache, and still did not start up as instantly as Vim does
2. Better keybindings - I would have used evil-mode but I felt at the time that it would be better to use actual vim.
3. Runs in a terminal window - Absolute necessity, so my only real choices were emacs and vim. I liked the workflow I had with `emacs *.py` or whatever I was doing but I thought at the time that vim would better support it.
A friend actually pushed me into using vim, which is funny because he uses the arrow keys with it... I got used to vim way quicker than I expected to, mostly because it was the only editor I installed at all (I switched from emacs to vim at the same time I switched from mac to linux)
Of course i do not recommend you switch between them but those were my reasons at the time.
I started out as a physics major, largely because I didn't want to lock myself into a practical career at the beginning of college. Spent most of my college career avoiding my physics homework by learning lambda calculus, and Haskell, and compiler design, and all of the impractical side of computing. When it came to get a job, I dusted off my Java and got a job in a financial software startup. Left it after two years after discovering that I hated finance but actually liked both software and startups. I've made more tech switches than I can count since, but it's always "Well, what do I need to know to get a job that will pay me and give me interesting challenges?" rather than "What do I need to know?"
You can choose to avoid all the language/framework/editor wars about which is better. None of them are better; it's just some are better for certain circumstances.
It's really a great time to be in software, despite the problems. The world runs on software and this will only be more true in the future.
You don't have to hit one of the pitfalls in the story. After all, printf himself ended up as a happy programmer with a human face. If you love programming and you can stay focused on doing what you love, then no matter what else happens, you win. And if you don't enjoy what you're doing, then you lose, no matter what kind of paycheck you take home.
This is also why managers that pick languages based on "hireability" are wrong for the most part. In any non trivial system, learning the domain and existing codebase will dominate the time to learn a new language. It's a nice bonus to have experience with a certain piece of tech, and for baby apps that might be the most important thing. But not for real systems.
This is what we want to be true.
It's not how 90+% of job listings are written, and I'm not sure it's how we hire.
Even if we addressed that problem, it'd still only be true at a close approximation: once a framework/lib/language becomes leaky enough, or has enough of a mismatch between its natural invocation and the problem domain, or carries enough of a culture of The Right Way To Do It™, then it's true that experience with the tool matters... as long as the org is more invested in the tool than a solution that doesn't have those problems, knowing the tool's foibles and practices remains important.
Getting a job is not a numbers game unless you just want any old job and really hate jobsearching. I've found that making myself unappealing to the organizations that I wouldn't actually want to work for has paid off significantly in both financial and job satisfaction terms.
This is 80% of what's out there though, FWIW.
JS has a very particular ecosystem and it certainly doesn't describe every other ecosystem in existence today. Basically what I'm saying is if you love solving human problems, software development is an intellectually stimulating and satisfying fields to get into.
I really like this quote, because I believe that it's nearly impossible to stay motivated fixing stuff over and over again in similar ways, year after year.
At some point you need to realize, that the systems we created can not give you complete fulfillment. There's always something better, faster, nicer. "The grass is greener over there" kind of thing.
I found my peace by being part of a family with 2 kids, doing fun game projects after hour when everyone's asleep and getting into drawing and music. Programming can be fun, but it's not the end of it all.
I genuinely don't understand. Do you not consider the organizational problems of society to be worth solving?
Technology made alot of stuff possible which would not be possible without technology. But the tradeof is, that we must live with systems which increase in complexity each year we use them. And there's no end in sight.
We developers in some way are trying to get out of the hole we dug ourselves into. Think about this the next time a framework comes along which solves all problems of the previous one. At some point you'd wish back the former days, when everything was simpler...
But I also hate how the world is different from what it could be if we as a whole cared about actually solving real problems instead of making money. The world could be optimized more. It's not. We've created lots of cruft and triviality. Even our tools of social interaction are designed to be barely working, the minimum amount of value that will still make people use it so that they can be monetized.
We've created really powerful technologies. And we're using them to like 5% of their capabilities for actually making the world better.
One I'd like to add is the developer who's so enmeshed in maintaining FOSS software that all they can do is label & triage tickets but never quite find time to start fixing them. I've found myself caught in that lately and am trying to figure out how to chip away at the ever-growing Issue Monster I've let form.
Don't prioritize based on what is the "fun technical challenge" but instead figure out how you can get users to be happier with what you are building. Also remember that sometimes the answer is code, and quite often it is documentation or a code sample showing the "right" way to do it.
And those nasty habits (ie trying lots of new crap.. complaining about existing crap) typically surface when I don't have a real problem to solve.
And that is the problem... my business is doing well but I just don't have any serious problems that are interesting to solve other than sales/marketing. I'm just not creative enough to find/create a problem worthy to solve that are not completely a mismatch to my current predicament (like I could leave my discipline and maybe do something else but I have obligations).
I really wish I had more creativity.
What a great read.
draw me a system ~ draw me a sheep
proud senior engineer ~ the king
rails -> nodejs -> meteor guy ~ the accountant counting stars
anyone have more?
I think Northern European languages like Dutch, Swedish or maybe even Polish might have a word which could better describe the sound? I can't think of any Croatian words that get close to it.
The best we can hope for, if we want to develop software for a living, is to live within our delusions and hope we're never unlucky then?
I've yet to meet even a CTO that doesn't get his hands dirty with code from time to time.
HN homework should be to re-read that section a couple of times.
https://news.ycombinator.com/item?id=3964475
printf is based on the idea implemented as early as 1956, next year it will be 60 years since!
1956: Fortran I:
PRINT 1, X
1 FORMAT (F10.2)
I/O in the first Fortran, I believe including the FN.M syntax, was implemented by Roy Nutt, also one obvious genius:
http://www.cap-lore.com/stories/Assembler.html
"There were a few pages of description of a new assembler format for the IBM 704 that differed considerably from the NYAP that we were using." (That) "704 assembler, originally called SAP, was written in its own language by Roy Nutt."
If you didn't read it I would recommend you do - it's possibly one of the most interesting and reflective things I've ever read about programming as a profession.
So if you mismatch the types you'll get a compile time error instead of a run time error.
http://www.codeproject.com/Articles/159910/Extremely-Efficie...