I hope that some part of the second half includes "don't use mongo".
Up to us. I think a lot of groups use it because it's easy to set up and forgiving to use for a small site. Why don't you like it?
Why use MongoDB when you could just store your data in dev/null?
It's great for losing data. I actually haven't used it in a long time but it has a very bad reputation w/r/t the guarantees it offers. It also, like a lot of NoSQL data stores, doesn't let you do cross-document joins, which really limits what you can do. Just use Postgres.
Through some combination of breezy documentation, unclear configuration parameters, lax defaults, and bona fide bugs, MongoDB has historically had a tough time meeting the four traditional properties one usually wants from a database: atomicity, consistency, isolation, and durability.
@aphyr is invaluable: https://aphyr.com/posts/284-jepsen-mongodb
Long story short: you'll want to think hard before using MongoDB as the system of record for data for which you cannot tolerate loss or corruption.
In seriousness, there are three things, Ogged:
1. Document stores like MongoDB are best suited for certain classes of problems.
2. MongoDB was hilariously broken under a lot of reasonably plausible circumstances; people who needed the things MongoDB was good at often ended up choosing a similar system built by someone else (notably Cassandra).
3. Early MongoDB (and NoSQL more generally, but particularly MongoDB) enthusiasts/evangelists were, uh, very enthusiastic, thus the "but it's webscale!" joke.
Well, I see we all read the same commentary on distributed data stores.
Another vote for Postgres. Never had a problem, although installs used to be annoying.
I do hope that you are at least getting a proper grounding in SQL before going into NoSQL.
I don't think proper groundings in anything are part of the game plan here.
I'd vote for MySQL over Postgres based on the "installs not annoying" grounds and because he documentation is superb. Although I guess its called "MariaDB" now because fuck Oracle?
That's basically right. The bar for retaining information is higher than you'd expect though. We've had closed book assessments where we've had to fully diagram the tables and joins for a hypothetical situation. Not a proper grounding, but not clueless either. And mongo was just one example, of course we've used SQL databases, too.
Oh, I have a question. Most people in the program default to deploying on heroku, because that's what gets used in one of the sprints, but is there something clearly better? I'm intrigued by Firebase.
Oh wait, Firebase is noSQL by default, with no other option. Nevermind. Too bad, because they make authentication really easy, and at least at this point, I find authentication pretty mysterious/difficult.
I feel like I should be thinking about doing some kind of coding bootcamp, but on nights and weekends.
Some of those exist. Bloc.io and something Foundry. Career Foundry, maybe?
Definitely not "learn this really well" as much as "get used to making things work that you barely understand.
Welcome to software! Seriously, you know that app you wonder how it got like that? That's how that app got like that.
7 is not me! I like mongoDB.
22 is the inside truth about 99% of software development.
It also, like a lot of NoSQL data stores, doesn't let you do cross-document joins, which really limits what you can do.
This thread made me peak at the documentation for the latest release, and it has added a basic join to the aggregation framework:
https://docs.mongodb.org/master/reference/operator/aggregation/lookup/#pipe._S_lookup
"get used to making things work that you barely understand."
This is more or less my programming approach. Maybe more like "Find half-understood code online that sort-of does what you want and modify it."
I'm thinking of taking a MOOC course on object oriented programming this summer. So far OOP seems to me like a vastly more complicated and confusing way of doing things, but hopefully I can clear this up. I'm uncomfortable with OOP mostly because I can't see how it works at the level of silicon. I'm comfortable enough with machine code because the connection to the hardware is pretty obvious. More abstract programming languages and methods make me increasingly nervous that I'm just trusting a giant stack of other people's work.
26
OOP has traditionally been hard to get ones head around, for some values of head. I would guess that most people encounter OOP first via Java, which until recently didn't allow methods to be first class objects. Trying to do simple functional programming patterns (map-reduce...) without first class methods is tedious and more than a little counter-intuitive.
I guess that once you go applying for fresh-out-of-bootcamp type jobs, you aren't going to have much choice in the framework/database you end up using anyway. So it does make sense to cover as many of them as possible so you are able to check the widest array of boxes on your resume. And to have the experience of getting up to speed on a new technology in a short time-frame.
get used to making things work that you barely understand."
STARTUP LYFE WOOO
Definitely not "learn this really well" as much as "get used to making things work that you barely understand.
Welcome to software!
And life, for that matter.
This is more or less my programming approach. Maybe more like "Find half-understood code online that sort-of does what you want and modify it."
Hey, that's what I do! Does this mean that I can call myself a programmer after all?
It feels like being repeatedly thrown in the deep end, with only (often shockingly poorly written) docs, vague instructions, and a tight deadline.
yes, that's the job.
32: at this point I realise I've been speaking prose writing code all my life.
Okay, the point has been made that "get used to making things work that you barely understand" is indeed the name of the game. A few addendums to that: 1. Not just startups! 2. It's when you think you really do understand something that you're going to get in trouble.
29: That's developer life, period. If you knew how it worked it'd already be done, and be done correctly.
35: Sometimes I think I'm a pretty crappy dev and not really growing at all, but then I remember I make many fewer off-by-one errors than I did a decade ago. I think that's really all you can ask for.
36:
I stopped making off-by-one errors almost entirely (because I work in Python).
We have a tool where values are internally zero-indexed (because Java) but exposed to the user as one indexed (because they like it like that), leading to all sorts of fun conversion issues.
While language/library choice can reduce fencepost errors, it certainly can't eliminate them; I think they're fundamental to some problems.
Sometimes I think I'm a pretty crappy dev and not really growing at all, but then I remember I make many fewer off-by-one errors than I did a decade ago.
Heh. I have days like that.
More seriously, I think the OP sounds like excellent skills for the bootcamp to be teaching.
I will say, one of the things I like about my work environment is that both myself, my co-workers (and many of our contacts as the big multi-national that we work with) stay in their positions for a long time. So while I have the experience of trying to make something work with minimal documentation, I also then have to field questions about it any time something doesn't work, and after a couple of years of that I get to know it fairly well (and, thankfully, I can do the same thing to other people -- ask the person who wrote something six years ago to investigate an issue and figure out what's going on).
Also, good luck to Ogged in the second half, and I would treat the projects as your chance to dive deeper into the concepts or technologies that you breezed through in your short sprints but want to explore more. Except for authentication. Let someone else do that.
40: My environment's like that as well. I'm in the lower half of time on my subteam (n=4) and I've been here for almost nine years. It's nice. On the other hand, we've had a lot of externally driven changes that mean that the answer for why something is weird is often "it made sense at the time."
40/42: I used to work in an environment like that and I miss it. But if I went back to a place like that I'd probably miss other things.
I find authentication pretty mysterious/difficult.
You and me and everyone else on the planet.
I tried Googling "OAuth2 is a miserable failure" and got results about George W. Bush. Yeesh.
26: In general C++ is a horrible monstrosity, but The Design and Evolution of C++ is a great resource for understanding how an OO language works from the ground up. Other languages just rip most of the knobs off the control panel.
Neither C++ nor Java is an object-oriented language.
You can tell because they don't have proper tail calls (cf.).
So, programming without adequate documentation is a vital skill, no question, but we have failed as engineers if shitty documentation has become such an ingrained habit that we train for adapting to it rather than fixing it. In my utopia, for every five or six coders, there's one dude whose job it is to write things down. Sumer managed it, why can't we?
All these lovable foibles of the coding lifestyle seem like they could be improved if they would hire 1/3 more people and pay them merely outlandish salaries instead of outlandish + 33%.
Meh, a lot of the stuff you hear about is somewhat blunted by Bay Area/NYC cost of living. Salaries are nothing to complain about everywhere else in the country but not really obscene.
The way to do it is to live somewhere cheap but tolerable and get a remote job at a Bay Area company. Then you make Bay Area $$$ without the cost of living increase. I know a couple people who have done that.
Since I give 110% when I code, I make off-by-two errors.
47. "No true object oriented language..."
50. Yes. Even when documentation exists it is usually just a compendium of all the commands/features/flags/etc., rather than saying anything even remotely near the "Why?" of a method or class or message or what-have-you.
Resources like StackOverflow have actually made it easier to skimp on documentation. Why write anything beyond the minimum when any question will be answered there? Except for fiddly detail stuff that isn't covered by my IDE I usually end up at StackOverflow. It is usually the first couple of results returned by Google.
Of course none of this is true about internally developed proprietary code. You can always ask the authors about that ... until they leave for another company. Oops.
re: 50
My place tries, and we are getting better* but we are funded by the state, or through funding bids generated by academics.** So no fucker ever wants to pay for anything, and every single part of IT costings is quibbled or top-sliced.
* one of my new jobs is to make everybody get better.
** who are basically arseholes,*** when it comes to this sort of thing.
*** not you, academic who might work with us/me, and who accidentally stumbles across this. You are a paragon.
47. "No true object oriented language..."
I would be more sympathetic to that line of rebuttal if there weren't clearly things that do qualify as object-oriented languages by Kay's lights, such as, unsurprisingly, Smalltalk.
Sumer managed it, why can't we?
But if Sumerian code was all that, why do we all write Akkadian?
oh ttaM -- I am in the very-merely-dreaming phase of trying to get a grant for something that would involve connecting people who make (user-unfriendly, poorly-documented, weirdly implemented) tools for digital research in the humanities with (a) the idea that they should incorporate project management and UX into their budgets and plans, and (b) people who can help them figure out how to do that better. Maybe I could get you to come give a talk!
You and me and everyone else on the planet.
A couple guys on our team got it working no problem, which is to say that one of the most salient parts of the bootcamp experience is how often I feel like the dumb kid. Some things I get and can do, no problem, but generally speaking, "programming" is not quite in my aptitude wheelhouse, and it very much is for some of the other people in the group, so there's been a lot of "wait, how did you know to do that?" in my pair sessions. The concepts generally aren't difficult, but there are so many different tools, each with their own syntax, and my 40-something brain is much more sieve than sponge.
generally speaking, "programming" is not quite in my aptitude wheelhouse
FWIW, "debugging" is more in my aptitude wheelhouse than the initial "creating something from scratch" part of "programming."
Thankfully programming is mostly debugging so I don't think that's a problem.
re: 59
I'm currently trying to get people who write funding bids and project plans that involve us doing work, to actually f&cking talk to us before they apply for funding.
'Hi, we have a £20K grant from $foo, we want to build [gigantic, feature rich tool to work with complicated 'dirty' data], we've budgeted £12K for us to publicise ourselves and our research, and we have £5K for you to do all of the work.'
I hyphenate capriciously.
If it's seven letters, it might be DASHING.
I wish I was in the habit of commenting. I used to think of it as the last step but I've since learned that no program is ever finished. Now my problem is that most comments I'd write are superfluous; my code is just too clear and self-explanatory.
I am pretty good at having explanatory docstrings, inline comments, and so on. I write them as I go, so it's not an afterthought. It's more the putting-in-context and explaining-why stuff that lives outside the code that I tend to be a bit slack about. I usually write it, but it often ends up as a txt file in a git repo, rather than nicely formatted in our wiki or knowledge management system.
62: Ditto about debugging. I consider it my greatest skill, as I am so good at regular bugging.
65: Sometimes I write comments first, as an outline, and then fill it in with code (with additional comments for tricky or unintuitive bits). I find this works pretty well.
68: My thinking, such as it is, is highly non-verbal, so starting with a description is a good way for me to grind to a halt.
I am procrastinating badly, and making slow progress, on my current task precisely because it does involve creating something new. In this case, an administrative interface to configure new functionality. The interface isn't complicated, but working on it I keep pausing because I'll start looking forward to imagine exactly how this piece is going to be used and how it will fit into the existing code.
All of that is part of the process, and legitimate work, but part of me feels like I'd be better off if I could just buckle down, finish the interface, and then have something to play with as I think about the rest of the stuff.
looking forward to imagine exactly how this piece is going to be used
Oh god, the human interface. If I go down this road I inevitably conclude that every command line should be Turing complete. I'm not the most productive coder ever.
||
This article about the dumb thing Carson said about the President is worth it for the picture and caption of Obama.
|>
... unsurprisingly, Smalltalk
"No true object oriented language is ... actually used by anyone."