I can see the bit about using a text editor and a command-line, instead of an IDE to some extent, especially if you are learning an interpreted language. But with Java, I want a run-time debugger and JUnit, for example. Should one learn how to use ANT and git or subversion from the command-line?
These threads always make me ponder if I'd make enough money to buy land to put a cob house on if I switched to programming.
I found that working through Learn Python the Hard Way noticeably improved my casual coding ability even though the first 1/2 of the book covered basic stuff that I already knew.
I prefer to use version control systems from the command line, but that's highly path dependent--Eclipse is our preferred development environment but we manage dependencies with Maven, SVN is our version control system but about half of us use git-svn as a layer on top of it. In general these plugins do not play well with each other, so the more I can do from the command line the less I'm exposed to things breaking for stupid reasons.
But honestly it's probably more important that you know the model the VCS is presenting than to know any particular way to interact with it.
I use git from the command line -- and teach it to non-programmers -- because probably I hate myself.
That would also explain the graduate school.
5: Me too. It is worth mentioning that the git command line interface was clearly designed by a sadist.
As for the article itself, the advice is mostly sound advice for a generic programmer. It's not too different from the received wisdom, though, which makes me think that most developers are doing uninteresting things. Type safety? Static analysis? Functional programming? Hell, where are compiled languages? The things they teach you in CS classes don't matter--and yes, I fully agree that they usually don't matter and it would be better if the programmer educational pipeline contained more about software engineering practices--until they do.
The Microsoft integration point is true, but I hear of a lot of cool stuff happening in C#/.NET. Likewise about mobile dev being not necessarily a great place to learn. PHP is horrible. I like Java, although I could like it more. Contributing via github or whatever is a good way to get your feet wet and learn to code with others.
The others will take you on a wilder ride, but you will probably have to learn things a few times as the community changes its mind about how to solve a problem. This is extra true for Node and less so for Ruby -- which reflects each community's age.
This is an awfully indirect way of noting the Ruby and Node communities' generally more rampant than average sexism.
Also I wonder if it's really true that Erik Meijer and Simon Peyton Jones don't number among the best engineers.
I use git from the command line, too.
The IDE thing: we hired a dev from a highly Microsoft centric background, although she assured us that working with python, MySQL, Solr, etc would be no problem. She, literally, spent (and I repeat, not an exaggeration) months bemoaning the lack of an IDE. It basically turned out that she was so reliant on Visual $foo that she was unable to work without it. She was an IDE user, not a programmer.
I use editors with syntax highlighting, etc but no real IDEs because the nature of what I do is 'bitty' and I've never had time to find the right one (if one exists).
Likewise about mobile dev being not necessarily a great place to learn.
What about mobile dev makes it a bad place to learn? I need ammo for my "don't put all your eggs in the mobile dev basket" paper.
which makes me think that most developers are doing uninteresting things. Type safety? Static analysis? Functional programming?
Most developers are doing deeply uninteresting things, from a technical perspective; they're only doing interesting things to the extent that the mundane programming tasks are being put to things that are interesting independent of how they happen technically to be approached. Tomn's post is slightly depressing because it's basically advice on how to do a bunch of more or less rote boring shit, but then, that's where the money is.
I've never found an IDE that really spoke to me but I am sure loving the shit out of ipython notebook.
Here's a question for the people paid to program: what do you actually do? Not a bunch of recursions, I gather. But on a typical coding day at work, what problems are you solving? Or what are you building?
I would use git from the command line more if I weren't neglecting my static-site blog.
11: IDEs are just such a boon. Being able to trace back all possible calling stacks is an amazing tool. Refactoring becomes trivial. Integrated debuggers--especially with hotfixing!--are lovely. Incremental compilation! If the nature of the code you're working with doesn't allow it, so it goes, but man oh man do they save time.
12: I was mostly just agreeing with his point about it being sufficiently unstable that that might be bad for learning; otherwise, take my opinion with a grain of salt because I'm not a mobile dev myself.
13: Yeah, that. (Of course, some of those rote things could be approached in a more interesting way that would probably lead to a better product, but that is not the path we went down. )
True enough to 18.last; I would really rather be using Haskell or OCaml to do my mostly not that interesting stuff, though that said I'd rather be using the language I am using than any of the three Tom recommends. (Though of the three I would go with Python too.)
But on a typical coding day at work, what problems are you solving?
I spend most of my time writing programs that convert data from $CRAPPY_STUPID_FORMAT to $NICE_BEAUTIFUL_FORMAT, and making user interfaces for visualizing and navigating the $NICE_BEAUTIFUL_FORMATed data. And of course, building connectors to the $CRAPPY_STUPID_BACKEND.
Also, I spend a lot of time not coding, mostly writing stuff that explains technical shit to non-technical people.
re: 15
I'm largely paid to run digital library projects. But part of that still involves coding. I'm not one of the main developers who'd be producing code for public consumption, generally, though, as I'm more hacky and both less by-the-book, and less competent than our full-time developers.* Much of what I do is grabbing data from one place and in format, and pushing to another place and another format. With a focus on bibliographic and structural metadata [stuff describing digital objects, largely digitised manuscripts or rare books], and on images.
So, this week and last, I've been working on creating proof of concept code and test implementations of a method to get metadata [in Dublin Core and METS] via http from our repository [which has a REST API]. Using that to generate XML in a slightly different implementation of DC, and push it into a Solr index that runs behind a search and discovery interface. Then use that information to create a resolver which links identifiers in that system with image content [jpeg tiles generated from Jpeg2000 masters] that can be provided by a tile server.
Does that make sense? This is quite standard stuff for me, but it's a new platform and a new repository structure, so it all needs to be tested and largely done from scratch.
My code isn't likely to be production code. But it will let me test stuff, probably be used to initially populate a production system with real world data [thus meeting project deadlines] and then let me provide a really detailed spec, description of the architecture, outline of any got-yas or obvious pitfalls to the devs who might do the production code, and so on. It'll also let me do some performance testing so I can go and kick sysadmins in the balls.
* I am however, quite quick, and much more familiar with the subject matter and the use cases than our 'proper' devs.
Do either of you use regular expressions...regularly?
15: Recently, most of the code I write is used to instantiate domain specific models with the necessary bits of computation that the domain specialists can't easily handle (that should be sufficiently vague, I hope.) This has been someone hampered by us being in the process of changing the underlying technology in a rather significant way; in the past four years we've gone from a Java desktop app to a Java applet and we're transitioning to a fully web runtime with most of the old logic being compiled to Javascript, while simultaneously building new content in this framework. (It's been depressing watching how slowly this has progressed relative to the skyscraper they're building a few blocks away) I've also been refining the tools our specialists use, and I used to do UI development when we were comparatively understaffed.
If you meant what I do day-to-day, a lot of debugging, planning, helping other people resolve their issues, trying to explain why I'm late on my own. Writing new code is usually a small portion of any given day. (This may be why I'm fairly burnt out right now.)
re: 22
A fair bit. I wouldn't say I find they come naturally. It tends to be trial and error. But yeah, I'm often doing lots of things of the type: find files of a particular type, where the naming scheme matches some pattern or other, and then move them and rename them to some entirely different pattern, say.
22: Yeah, pretty often. All the time for command line grepping log files or whatever; somewhat less so for string processing in code but it does happen. The jwz "you have two problems" quote is somewhat apocryphal, regexes are awesome.
15: right now I'm more or less trying to figure out various ways to throw a whole bunch of high-dimensional data at a model in such a way that it'll return informative stats about how the model works before the heat death of the universe. So it's basically a lot of figuring out where I can do dimensionality reduction, how to make the models work in the first place, and then how to get everything running nicely in a parallel fashion on the university's cluster. And after that it's just little optimizations so it doesn't take forever and ever.
Although did you mean me? I guess I don't technically get paid to program, per se. In a few weeks I'm going to be starting a more normal project (redoing a relatively simple interactive site to use flask on the backend instead of PHP).
I ask because although Tom mentions it, a lot of people giving advice to newbies don't, and it seems to be a pretty important tool in a lot of jobs.
I use regular expressions just infrequently enough that I have to look up the syntax every time. RegEx-foo is a skill I wish I had, but have never quite needed enough to develop.
I use regexps a lot for quick and dirty data pre-munging and occasionally in code, although admittedly it's generally code to do quick and dirty data-munging.
Not long ago I was writing a lot of Drupal modules in PHP. That sucked, and I'll probably have to do some more of it.
The only regular expressions I use with any regularity are quite simple.
20 describes my work fairly well particularly this:
And of course, building connectors to the $CRAPPY_STUPID_BACKEND.
But my work is almost never interesting from a technical standpoint (it is interesting for being able to provide practical real-world value for the users, but that's a different consideration).
A surprisingly large number of developers become helpless without an IDE.
svn has a perfectly nice command-line interface. Every time I read how to use git, the information escapes from my head immediately.
Using that to generate XML in a slightly different implementation of DC
Someone should run into an official Dublin Core meeting, tear up a copy of the spec, and yell: "Where's your 'lowest common denominator' now?"
I think that a lot depends on the volume of data that a task works with.
This remark in the OP, in particular, seems insane, completely wrong:
You do not need to know much about data structures,
Maybe he means that it's not necessary to rewrite basic algorithms that work with data structures. But not understanding relative cost:benefit of array, list, or tree means an inability to do anything in volume.
Lots of code that works with a thousand elements won't work with tens of millions.
And yes, echoing others above, format conversion is a common task.
Yes, Dublin Core came out of OCLC-brokered agreements.
If you do everything in SAS, you never need to change formats.
A surprisingly large number of developers become helpless without an IDE.
The advice to not use one seemed solid when I came across it. I looked into Sublime Text, but then I thought, fuck if I'm going to spend time learning to use a complex text editor when I should be learning to code. I use a little app called Chocolat (for Mac) that's quick, tells me which brackets and parentheses pair up, and makes the code pretty colors, and that's pretty much all I need.
Never is a long time. Has anyone from your institution come around to talk about dataset preservation?
39: I love Suime Text. It really isn't complicated.
re: 34
Yeah. And because the original DC element set is so lowest common denominator to be utterly useless, and everyone implements (and qualifies) DC Terms in different ways ...
We have internal arguments just on our (tiny) team about how we should do shit. I tend to be on team 'who gives a fuck as long as it works'.
it is interesting for being able to provide practical real-world value for the users, but that's a different consideration
This. Technically, what I do is pretty standard (beyond when I am writing toys for myself), but the real world problems are interesting. I wrote a calculator that draws a Google Map with a radius indicating how far away you need to keep your ammunition shed from populated areas. The code is not complex, but people are using it to make sure that other people don't get blown up in accidental ammunition explosions, which is immensely satisfying.
I also wrote a twitter bot that imitates a Magic 8 Ball.
I say this as somebody who loves me my vi(m) and loves going down to simple text-based tools when it's appropriate: it's good to know how to use an IDE. It will make modifying and exploring your code easier.
Although this dovetails with 36: techniques that you learn to work with a thousand lines of code might not scale to a million.
44: Yeah, I wasn't intending to complain about technically uninteresting stuff that solves real problems. That sounds very cool!
37: I was joking, but apparently I'm smarter than I know.
Yeah, I use Sublime Text, or Emacs.* Largely Emacs, I suppose, because I do 90% of everything in a terminal window. But I do quite like Sublime Text, although I don't use most of what it can do. I just use it as a text editor with syntax highlighting.
* although because I use a desktop mac at work, with a microsoft natural keyboard attached, and I'm often using 'screens', I'm sometimes so frustrated by trying to work out how the fuck to do M-% 'foo' or whatever, that I end up turning to the dark side, and using Vim.
And re regexes: I rarely use them (Python string methods FTW) but I explicitly got turned down for a job with the Wikimedia Foundation because they didn't think I was up to scratch with them. Take that for what you will.
I take 50 to indicate that the wikimedia foundation is utterly insane.
Go Team Vim!
I use regular expressions, but that's because of my background as a Perl developer; they're generally not idiomatic Python, and while they're reasonably idiomatic JavaScript, the less expressive methods for building them in JS tend to make them incomprehensible after a very low threshold of complexity.
15 - I've been having a bunch of design meetings (and doing code reviews) recently, but work I've written in the last week has also included updating one of our internal tools to stop pointing at a backend I'm trying to end-of-life and point at something better maintained (including updating unit and integration tests), teasing apart several hundred lines of poorly documented SQL stored procedures written by someone no longer at my company, and investigating the world-shattering question "why is this ad showing up twice on this website in IE9 when it should only show up once"
This thread is so reassuring. My Java book just had me coding a simulation of a self-avoiding random walk, which is not really all that complex, but I'm only about a quarter into the book and figured I'm hosed if this gets a lot harder.
I discovered the most insane thing about SAS. It stores all numeric data as a floating point number. For example, it stores dates as a floating point number. This probably is of no practical signficance, but it never would have occurred to me as a possibility if I hadn't read it in the documentation.
Dates are days from January 1, 1960. Just like in the Bible.
I don't understand 53. You're reassured because nobody is implementing random walks?
54: Integer, floating point number, who really cares? The important question is, seconds or milliseconds?
Days are integers, Moby. Using floating point numbers is the exact heresy that caused the Bogamils to be suppressed by the Catholic Church. Even Martin Luther wasn't willing to go that far.
Days are integers
How many days is it since 10PM August 4th?
57: Days. They use fractional days, either.
I mean they don't use fractional days.
Josh may actually be too innocent to understand SAS.
You're reassured because nobody is implementing random walks?
Correct!
SAS date representation is so important it deserves 4 comments by me in a row.
If you still use punch cards, it probably doesn't matter.
I was very excited when I learned the command to include data in a SAS command file was CARDS. I think even Cobol hides its ancient mainframe heritage better than that.
7/13: I'm not sure I get that much out of working on interesting problems. I've never heard anyone say that with respect to programming, so this is probably considered crazy.
I just quit my job a couple weeks ago because I didn't like the work environment, even though the technical part of the work was about as interesting as it gets.
I started my career doing the most uninteresting possible thing, debugging regression test failures. Over the course of a decade I worked my way into groups that do research, create bleeding edge systems that can scale up orders of magnitude past the equivalent open source solutions, etc.
I certainly don't have anything against working on interesting problems, but I think the most important factors in whether or not I'm happy with my job are the team, the manager, the level of bureaucratic nonsense, the amount of political infighting I have to put up with, etc.
63: I'm using an optimization algorithm that is random walk-ish, but I didn't have to implement it myself.
Yeah, you're doing science-y stuff, which is what this book is geared toward. It's not quite my bag, however, so while I like learning this way, I'd rather not have to learn a new theorem every time I want to code something.
65: Back when I started my career, one of the programs I worked on had an unusual structure. It was written in Fortran. Each subroutine was approximately 2000 lines long, mostly straight-line code with maybe a couple of big loops, and then a handful of subroutine calls right at the end of the routine. When I inquired about this structure, the answer was that the original programmer had a practice that one subroutine == one box of cards (which could hold 2000 cards). He would just write his code as one big flat routine, and then when he got to the end of the box, create a subroutine call or two and continue with the new subroutine in the next box. This structure continued long after they were no longer using punched cards to store the code. This made his code a challenge to understand and maintain, since there was no real functional cohesion to his subroutines.
69: ah, yeah. In the normal programming world that very seldom comes up, and is a delightful change of pace when it does.
You should go back to using punch cards to store data.
Life is like a box of punchcards.
I saw 70 in Java once. They had a long list of simple validation and enrichment rules to apply to incoming data. A Rule interface and some sort of data structure was obviously crazy talk, so they had a runRules() method that ran every validation in sequence. Eventually they had enough rules to blow the compiler limit on method length, triggering a considered refactoring of the method to invoke runRules2().
At least the other guy had the punchcard excuse.
55: the epoch is from 1970, not 1960.
At a guess I wrote about 100k lines of a mix of mostly c++ and little c# in the last year most of that concurrent numerical codes. A bit of low level stuff too. Having a good editor (e.g. emacs) and knowing your way around it makes it much easier to actual write, but on the other hand if you have a couple million lines of Java or .NET stuff to navigate around, without a good IDE I spend all my time looking for things. Particularly if I do t know the code base well, the IDE is a godsend...
I don't write much code anymore, but when I last did a few years ago it was mostly about extending and rewriting relatively, but not astoundingly, fast message processing systems to accommodate features of the domain more general than the simpleminded model of the location they were written in. And fighting with vaguely defined protocols for those messages. And sometimes adding some new features.
Is this really what you all spend your time discussing in my absence? I feel so indispensable.
So for the rest of you, programming isn't mostly about figuring out what combination of compiler flags and minor code changes it takes to get old Fortran 77 to compile with gfortran?
12: Mobile dev is a bad place to start because so much of it is dependent on the system API that a beginner will have absolutely no context for anything. Especially at the start, you're just filling in a bunch of template methods because that's what the book told you to do, and whether or not your emoji pedometer app crashes every time you change screen orientation is a matter of pure magic.
81: Change "old Fortran 77" to "open-source C++ libraries" and "gfortran" to "iOS 7.0" and you have about half of my job.
do
You can write fortran programs in any language.
end do
The other half is, again, taking data in one format and turning it into a different format, relying extensively on regular expressions!
A couple of years ago I had interesting problems to solve. Right now we're just trying to stay in business by pulling money out of the app stores, which feels a lot like siphoning gas out of people's cars.
BREAKING NEWS:
Computer programming, in other words, has become a trade. Like nursing or welding, it's
something in which a person can develop at least a basic proficiency within weeks or months.
http://online.wsj.com/articles/computer-programming-is-a-trade-lets-act-like-it-1407109947
That is not a thoughtful article. Deadlines are a bitch, I guess.
90: babies learn to nurse within days, IIUC.
In journalism, people don't develop a basic proficiency even after years.
82: as against new F77 code?
Eh, it beats trying to get F95 code to compile. Although dynamic allocation is nice.
I like these discussions because it's like reading a foreign language which you sort of but don't really speak.
I especially enjoyed all the responses to 15, I used to have no idea whatsoever what you all do and now I only sort of have no idea whatsoever what you all do. Are solving these translation problems or whatever fun and intellectually engaging?
I had a kind of fun translation-like task recently; something like query de-optimization to get around stupid limitations in one of amazon's services. For the first time in my adult life a practical use for knowing what conjunctive normal form is!
||
Saw some guy totally rocking some shiny black leather shoes with Cuban heels and totally envied his footgear just now.
|>
Since he was shod, however, I was unable to carry out a toe tally.
I basically do no programming but I spend a lot of time doing command line things. Mostly I've been testing some software my work may use. I'd like to contribute code to some projects at some point.
95: Usually not in themselves, at least not for me, but there is fun and challenge in trying to come up with general solutions. If I have a data-shuffling problem that has something in common with data-shuffling problems likely to emerge in the future, then I can try to write or extend a tool that will both answer the present problem and obviate the rote parts of future problems. This means it takes longer the first time, but hopefully you make it back later. If you don't, then you just over-engineered the problem and created something snazzy and unnecessary.
I think what most people have described here is the grunt work of programming--probably like the boilerplate in a brief: you have to understand the situation and know the customs, but you're not really solving a puzzle. The thinking gets sprinkled in when there's something in the situation that's novel or unusual.
I guess I just described every job ever. My point, if I had one, is that this thread doesn't give you a sense of what might be interesting about programming.
My first paid programming job was revising some Fortran 77 code for use in a lawsuit. I think the code originally came from NASA.
I mean, even converting something from format $foo to format $bar in a general-purpose way can be pretty fun. You're building a machine to disassemble this big complicated amalgamation of nested stuff all full of special cases and so on and then reassemble it, whatever it is, into a whole new thing, preserving everything important about it, and you can ideally write something to do this for any $foo. Neat!
Let's see, what am I doing when I'm coding? These days, I work on a system that processes large piles of user action logs, distills them into a smaller pile of summary statistics, and then uses those plus a bunch of heuristics to decide what does and doesn't go into a couple of different layers of caches, with the goal of making future user actions fast and relatively resource-efficient on the server side. Right now I'm trying to make this whole process faster itself, so that it's easier to experiment with different heuristics. This grew up as a linear pipeline of C++ and Python programs, and I'm rewriting them to be more parallel, to take advantage of the fact that we do, after all, have more than one computer.
The low levels of this involve reading and understanding code in both of those languages (and a couple of specialized sub-languages) in their linear idiom and picking a less-linear idiom, possibly in a different language, to translate them into, and writing tests and test frameworks along the way so that I can make sure I'm not totally changing the computation when I do this. Some change is allowed, so writing the tests to decide when two of these large resulting intermediate data structures are "close enough" is a decent project in its own right.
And I'm also supposed to be expanding what we cache on a few different axes, and adjusting these tools to make that possible and repeatable, and then evaluating whether those expansions are a good idea or a good value along certain metrics.
And at the end of the process, the NSC decides who to kill with a drone strike.
101: I have to be a bit vague, but I feel there is a bunch of interesting stuff in what we're doing. Both from the purely technical (non-convex optimization problems in a bunch of dimensions, real time data fusion with high resolution, interesting physics modelling, etc.) and from the problem domain - we're working on tools to directly help experts do a better job of saving lives.
Some of that implementation is hardware, and some of it is software and , honestly, some of it is pretty pedestrian but needs to be done. But the rest of it is pretty interesting.
High dimensional data is such great fun. You get to wander around in ten-thousand dimensional space! Freaky-deaky.
96.2: Searching for "Cuban heel" got me this. Is there something you want to tell us?
109: Unless you're using autocomplete, I think it tells us more about your search history than neb's sartorial preferences. When I search, it comes up with the expected definition and images of men's boots.
111: I didn't know you had a men's boot fetish!
I get about 80% shoes and 20% pics like Josh found. Maybe you have safe search on?
Anyway, I guess that's been one of my increasingly? rare flyby comments... Have fun all !
I think the difference might be whether or not you are searching images. Because just searching the web gets you almost entirely men's boots.
116: It was actually one of the image ads in the "sponsored" box on the right of the search results.
"Cuban Heal" is apparently a cocktail.
A "Cuban Heil" is a Nazi salute with a nice pork sandwich in your hand.
I do see the same stockings as sponsored (maybe fifth or sixth) or low on the first page of hits in a web search, but they don't feature prominently. I see pretty much all shoes for the first page of images (mostly men's, some women's), and SafeSearch isn't on. 111 is clearly correct. Blowjobs (now with added grapefruit) and men's boots, thank god Google gets me.
"Cuban teal" is one of the Miami Marlins' colors.
This seems like the place where I should confess that someone in a position of authority taught Mara and Nia a Sir Mix-a-Lot parody, "I like big books and I cannot lie!" which would be fine except they've independently decided to make it more scandalous by imagining it could be "I like big BUTTS and I cannot lie!" at which point they fall about laughing and can't even go on. If Borges had written a parenting manual, I would know how to respond.
(Also, it's normal to read threads like these and feel guilty for not having gone into programming so that conversations like this wouldn't be entirely between men, right? And yet I didn't, and undergrad philology is probably not sufficiently gender-bendy at my age anyway. But something.)
That is a really, really good story.
I especially enjoyed all the responses to 15, I used to have no idea whatsoever what you all do and now I only sort of have no idea whatsoever what you all do.
I was thinking the same thing.
Further to 124, Borges is Top Relevant, but I guess they're now also going to have that moment in A Portrait of the Artist as a Young Man when Stephen sees a dirty word carved into a desk and is shocked to realize that other people independently arrive at his own scandalous thoughts.
96.2: Searching for "Cuban heel" got me this. Is there something you want to tell us?
Honestly, Josh. The Cuban heels in that image aren't even related to shoes.
but you're not really solving a puzzle
If I were doing programming, it would probably be along the lines of moving stuff from one format to another, and I'll probably be working on that at some point in the future, except I may not be the one who writes the final scripts or queries or whatever we use. But my actual job is working on the problem of how do we keep stuff that is in digital formats for basically forever* while also making it available for people to use?
*Or at least until we, or a successor institution, decide to delete them.
One of the most satisfying/interesting things I did for my actual job was this (sadly the README is out of date, oh well); the other thing isn't publicly linkable but it was pretty cool too, man!
Actually I think I did several pretty interesting/cool things for my job, just not for a while.
124: Hilarious! If only you had then pretended to extend their version with the actual lyrics.
A typical programming task for me is: a user wishes this screen would say "your foo has 3 bars" and the part of the code that knows about your bars is over here and the part that knows about your foo is way over there; how the hell am I going to pass the bars from there to here without poking holes in every module in between?
... and actually solving that problem is kind of trivial, and also kind of irritating, but also kind of fun, like solving a Sudoku.
Kind of, but there's a subjective quality to it: did you just bind together disparate modules into a way that will make them an unmaintainable monolith?
136 gets it right, except mostly less fun and more irritating than Sudoku. Maybe 2048.
As if Yawnoc's empoyer cares what users wish. Well, maybe these are internal users.
Also, maybe 99% of the problems you solve will have you cursing your idiocy in not noticing the solution earlier. It's the shaggy dog of puzzles.
141: only insofar as it reveals that he works for a tech company.
142: "solution" s/b "problem". It's remarkable the number of hours I've wasted in my career solving what I incorrectly assumed to be problems, only to discover that the real issue was something else entirely.
If you like having puns explained to you, you'll love fixing bugs.
But heeeebie, the method was reaaaallly loooooong ....
142: those are the good kind are problems. The bad ones are where you actually couldn't have possibly know the real issue.l and only discover it by dumb luck.
My biggest annoyance is trying to reproduce a bug that works perfectly in my dev environment. It's odd to be happy to have your stuff break.
I work in the general field of Electronic Design Automation, which I informally describe as "software to help hardware designers design better hardware." Lots of data-structure stuff (often working on data structures several levels removed from the original design data), lots of legacy code that needs to be understood and modified*, with the potential for algorithmic innovation**, but a lot of more routine stuff that needs to be done to get a product out the door. Requires knowledge of both hardware and software, though a lot more of the latter. Mostly C++ coding these days. Currently working for a small EDA company, where I've just seen the project I've been working on become the centerpiece of our new release, which is pretty satisfying.
* - I've noted that in a 30+ year career in EDA, there's only been a couple of times in which I was starting a project completely from scratch, and one of those was my dissertation project. Most of the time, I've been extending, interacting with, or incorporating a significant body of preexisting code.
** - EDA has a bunch of problems that can be described as "trying to find a better near-linear-time heuristic to solve a bunch of practical cases of a known NP-hard problem." If you know enough CS theory to understand the jargon in that expression, you probably understand why that can be hard. If not, let's just say that it's a field where one person with a bright idea can sometimes make a big difference, but most of the time, you won't.
Lots of people at certain companies near my workplace must be on vacation or something because traffic has really let up there in the last couple of days.
Everyone's at Burning Man with Grover Norquist?
138: I find work more fun and less irritating than Sudoku. I actually refuse to do Sudoku anymore because I just do them compulsively and joylessly; they make me kind of anxious.
I have no idea what a WIE is, or if 140 is one.
150: Yeah, I figured there had to be a reason. It's been interesting to see the contrast among the public infrastructure everyone uses (freeway much less crowded right now), the public infrastructure some people use (non-company-specific bus/shuttle about as busy as usual, northbound train maybe marginally less busy, don't know about southbound), and the private spaces people who don't have certain amenities use (lunch places are about as busy as usual, presumably because people who go to them don't have in house cafeterias).
146 seemed funnier when I hit post six hours ago, then walked away from that computer.
WIE: Weapon of Indiscreet Errorism
Re: 129
I do that, too. Except I tend to be involved in both the 'how do we get digitised stuff* into the forever-keeping-place and once it's there how do we deliver it back out' problems, and not so much how the forever-keeping-place is built.
* starting right from the physical thing, and working right through the process.
Re: 129
You know that obviously, as we discussed it. 157 more for the general discussion.
I like that revealing what WIE means would now be a WIE.
This is such good advice.
Master the art of googling for error messages. Using search engines, Stack Exchange, mailing lists and IRC properly to uncover unknown answers is maybe the most important skill in real-life programming.
So many problems can be resolved by constructing an intelligent search request. Partly, this is because constructing an intelligent search request requires forming a well-specified hypothesis about your problem.
160: True, but I wonder just exactly how green this kid was that "use Google and Stack Overflow" was helpful advice...
159: Searching the archives reveals that an unreasonable amount of German is quoted around here, and neb shouldn't worry about it.
re: 161
You'd be surprised, or maybe not, by how often I have to tell people how to do that. Or how often some problem that a colleague has been apparently struggling with for 'weeks' is soluble [by me] with about 15 minutes, and a bit of Googling.
163, 161. In getting computer work done, there's a set of tasks orthogonal to actually writing code and analyzing the problem at hand. That's setting up a working stack of components.
It's a super-useful skill, only sort of similar to programming, much easier with google+stackoverflow over a manual. I hate doing it, not as good at that as the other stuff.
We have a new programmer in the lab who is very competent but basically used to C programming circa 15 years ago, and it is so impossible for me to get him to believe that the google + stack overflow process works.
163: I had this experience with a new postdoc in my lab who is working on mainly computational stuff. I was surprised at how hard it was to get her to adopt the habit of google searching the problem first, instead of struggling with it on her own for days and then searching as a last resort.
A useful complement to Stackoverflow for new programmers is thedailywtf, rich with examples of thoughtless cut-n-paste.
http://thedailywtf.com/Articles/Code-Abuse.aspx
I may be guilty of thoughtless code abuse. My programming style is basically to look up examples code on the web, cut and paste it, and make required modifications so it works with what I've already got. I'm a relentless code plagiarist. Usually at least half of what I write is directly derived from some source other than me. I tend to write shortish programs for doing very specific things (interpreting spectra, displaying diagnostic results, that sort of thing), so maybe my style doesn't scale very well.
167: I used to love Daily WTF, but I had to stop reading it; the more time I spend in the industry, the more depressing it is. (Great for impostor syndrome, though!)
165: There was a period where crappy answer sites completely destroyed the effectiveness of Google in searching for error messages. Maybe he thinks Stack Overflow isn't any different from Yahoo Answers, etc.?
Not in a programming context, but I've never understood why Yahoo Answers shows up on google. There's never anything at all useful on it, so I can't imagine anyone ever links to it, and yet it pops up to the top of all sorts of google searches.
170: Or worse, Experts Exchange, which would have a tantalizing preview of what might be an actual answer and the rest behind a paywall. Stack Overflow has changed things for the better. And the name itself is enough of a shibboleth that I'm surprised that they wouldn't at least look at it. Old dogs and new tricks, I guess.
So from the first thing I found at the Daily WTF, a warning against copy and paste:
Sometimes it seems the author of the copied code uses this effect to punish or tease the copying user... A colleage of mine copied a C# code fragment that contained an integer counter named "i". But it was the Unicode Character 'cyrillic small letter byelorussian-ukrainian i' (U+0456), which is really mean, because C# accepts unicode as source code encoding, so no compiler message points you to it. Only the helter-skelter at runtime (which looked like a brick got thrown into a washing machine) was a slight hint... ;)
That is nasty in an unusually refined way ...
Or worse, Experts Exchange, which would have a tantalizing preview of what might be an actual answer and the rest behind a paywall.
Now we have Quora with the same bullshit except you have to give them your Facebook credentials.
171. I don't know, but suspect that it has something to do with the Google reranking last December. Also the way Yahoo ANswers tags their pages. More and more often, people type "how do I kill my ex" instead of "undetectable poison."
173: the Hannibal Lecter of code-copier saboteurs.
lw is smart from the very beginning.