|
TooMuchAbstraction posted:Anyone want to give some advice on mentoring? I have a more junior coworker who's trying to transition towards the software ladder (from a somewhat less-technical ladder whose name I forget Sounds like you're already covering most of the bases. If I remember right, you assign work on your team? It would probably be helpful for them to be able to work in\with the same part of the codebase for awhile. Once they've got a good understanding of some part of the system they'll have a better basis for incorporating other pieces into their mental model. Since they're working in a new language, introducing them to good references for that language in specific will probably help them alot. That way they can look up new things themselves. Since it sounds like they're new to programming they may not be familiar with more general sites like StackOverflow in which case you might want to give them that too. Ideally typescript would have something like cppreference for c++, but I'm not familiar with typescript either so the best I could turn up in a few minutes with google was https://www.tutorialspoint.com/typescript/typescript_overview.htm TooMuchAbstraction posted:I think the team has good social dynamics, definitely they aren't being left out of lunch at least. I've sent them some code reviews of my work...haven't tried using them as a rubber duck though. Part of the difficulty there is that my primary domain is the backend, and they're looking at frontend code, so it's unlikely that any rubberduck-worthy problems I encounter are going to be comprehensible to them. I mean, that'd make them a great rubberduck for me because I'd have to break things down to a super-simple level...I just don't know how useful it'd be for them. I think doing at least some rubber ducking would be helpful in giving them an opportunity to see how you work through problems. Pair programming is probably better for that, and if you're already doing that there may not be much to gain here. You could also see if one of the other frontend guys is willing to help bring the transfer up to speed. Some of the places I've worked would pair engineers up in the same office with the expectation they'd help each other when they got stuck and then look for expert guidance if they were both stuck. Maybe ask one of the frontend experts for suggestions on files that only have good code in them and can serve as reference points. TooMuchAbstraction posted:Right, my big concern is that they'll just keep to themselves and quietly fail because they don't want to bother anyone "more important". But on the other hand I don't want to be intrusive either. You can keep track of their progress by watching for commits from them, this is really easy to do if you do code reviews but you can also just check every morning to see if they're making good progress or if you should stop by and ask what they're working on to give them an opportunity to ask for help or unstuck themselves by talking through what they're working on. This also will give you opportunities to train them to make smaller, more manageable commits. LLSix fucked around with this message at 04:50 on Feb 8, 2018 |
#
?
Feb 8, 2018 04:47
|
|
). They're basically getting dropped into the middle of a large codebase in a language (Typescript) that they've never used before, and they're struggling. Obvious things I can do include being verbally supportive, doing pair programming, answering questions, and checking in regularly to make sure they aren't blocked and/or despairing, but what else can/should I do?
|
|
| # ? May 17, 2024 21:35 |
|
|
Does anyone have any particularly useful links and/or anecdotes about peer reviews? I’ve never worked somewhere that did them and I’m wondering if I should start them where I work. For possibly relevant context, I’m one of about 10 devs in a company of 20 people. Devs are a fairly even mix of seniors/intermediates/juniors. HR/management consists of one person, and we have project leads but otherwise no real management structure beyond CEO <- everyone. I feel like we all have frequent opportunities to give feedback to one another, e.g. during code reviews or weekly planning meetings, but I’m curious about something more formal and with a wider lens than "this particular changeset in front of us". We don’t have any kind of formal performance reviews. I’m imagining something like: once every six months, for each dev in the company, you write down at least one positive thing and at least one thing they could improve on. You submit these to one otherwise uninvolved person (CEO?) who collates and makes sure nobody says anything egregious. Then each dev receives an anonymized list of feedback blurbs from their colleagues. Is "peer review" the right term for what I'm imagining? Does it look anything like how I describe? Does this work particularly well/poorly if there’s a direct connection to compensation? Is this just a terrible idea?
|
|
#
?
Feb 8, 2018 05:25
|
|
|
What you've described is a pretty common way of doing peer reviews/360-degree reviews. A company that I used to work for tried to implement that system and the responses varied from neutral to suspicion to vocal hatred. If management is involved, people might perceive it as a way for management to encourage workers to snitch on each other. In the end, we did one peer review round, maybe 20% of the office submitted anything on time, and then it was never mentioned again. They shouldn't be linked at all to compensation and that should be communicated unambiguously, or else you're opening Pandora's box for all kinds of resentment and petty behavior. fantastic in plastic fucked around with this message at 05:44 on Feb 8, 2018 |
|
#
?
Feb 8, 2018 05:42
|
|
|
pokeyman posted:Is "peer review" the right term for what I'm imagining? Does it look anything like how I describe? Does this work particularly well/poorly if there’s a direct connection to compensation? Is this just a terrible idea? This is broadly similar to how performance reviews work at Google (and, I would wager, at other big companies). It's both enormously unpopular with people who would rather get on with their work, and enormously important as a reality check about what you need to work on. In other words, it's a good idea, but be prepared to fight an uphill battle if you want to institute it where you work. At Google specifically, performance reviews factor into (but are not the sole determinant of) your rating (e.g. needs improvement, superb, etc.) and promotion options, which in turn affect your compensation. There's a huge bureaucracy over it since it's an obvious potential point for corruption, petty politics, racism/sexism, etc. The bureaucracy presumably would not transfer to a company with fewer than 100 employees, so you'd need to think carefully about how to handle complaints and try to ensure impartiality. NB performance reviews have never been popular at any company I've worked at, but not having them is far worse than having them. LLSix posted:If I remember right, you assign work on your team? It would probably be helpful for them to be able to work in\with the same part of the codebase for awhile. Once they've got a good understanding of some part of the system they'll have a better basis for incorporating other pieces into their mental model. Thanks for this, and for the rest of your advice. I'm not directly responsible for frontend assignments, but I can probably suggest things to the person that is. Good call on looking up references. I'm pretty sure we have some internal materials which may help. The big question is whether it's the language itself that's giving the dev trouble, the design of our particular project, or the libraries we're using. I can help with the former two, but documentation for frontend libraries appears to be universally a collection of badly-written how-to guides, instead of a reference. Like, it took me a lot of reading between the lines to realize that React is basically just pubsub. The dev's primary prior experience is with Python, which is at least in the same family as Typescript.
|
|
#
?
Feb 8, 2018 05:45
|
|
|
pokeyman posted:Does anyone have any particularly useful links and/or anecdotes about peer reviews? I’ve never worked somewhere that did them and I’m wondering if I should start them where I work. Sounds like a 360 review? No idea how well they work, but they’re supposed to fight cronyism/nepotism a bit I think? CEO would definitely not be an uninvolved party; I’ve typically seen them around bonus/promotion/etc tied up in the yearly review process. The way the incentives work out, I expect most people give positive reviews to almost everyone.
|
|
#
?
Feb 8, 2018 05:57
|
|
|
I've seen it done lots of ways, most of which I've not been involved in for years as a contractor, but one people seem happy with is matrix reporting? I think it's called? Whereby the person you do 1:1s etc with is not the person who manages you day to day, so you're able to report issues and discuss approaches to solving people problems with someone who isn't likely to be involved in them. This combined with a peer review where managers/peers get anonymised feedback but reports get named feedback seems to work well. Though these places have then coupled the reporting to money by grading on a curve and making managers fight in meetings for who gets to be marked "above expectations" which is just lovely.
|
|
#
?
Feb 8, 2018 11:01
|
|
|
IMO any review system you attach money to will be tainted so perhaps have some that aren't if possible.
|
|
#
?
Feb 8, 2018 11:41
|
|
|
TooMuchAbstraction posted:IMO for pair programming the less senior developer should be the typist and should always get first crack at any implementation (after discussing approaches of course). Then the more senior dev can point out cleaner approaches if necessary. On one project I did this pairing on, it was just me and one other engineer at the local office. We paired 100%, usually doing my assigned tasks in the morning (my hands on keyboard), and his in the afternoon (his on keyboard). Even after I was up to speed on the project, we kept doing it this way because we liked talking through the problems together and usually had at least equal if not greater velocity. Since you seem to be a bit more siloed, it might not work as well - is there a frontend dev you could convince to pair with this person?
|
|
#
?
Feb 8, 2018 15:13
|
|
|
vonnegutt posted:Since you seem to be a bit more siloed, it might not work as well - is there a frontend dev you could convince to pair with this person? Part of the difficulty I'm running into here is that our frontend lead is going on sabbatical, and our only other frontend dev is not a great instructor. I do think pairing them could be a good idea once the mentee is more up-to-speed, but I'd like to get them more comfortable with the system first; otherwise I worry that they'd just kind of sit there and watch the FE dev work without being able to meaningfully contribute. Especially since the FE dev is very driven to Get Things Done and tends to look for ways to circumvent things they interpret as friction (e.g. it took a long time for the rest of the team to convince them that tests were a good thing, as opposed to just a meaningless formality between them and getting their bugs closed).
|
|
#
?
Feb 8, 2018 16:29
|
|
|
So what's the deal with scaling? It's something that's come up often as a lot of companies I interview with say they're facing a bunch of problems in "scalability". From what I can tell, this basically means "we have so many users now that our systems are running like crap/we think we need to scale better", and can apparently encompass problems ranging from concurrency, to parallelism, to spinning up new AWS containers. Scalability is something I have little to no experience with or knowledge of, but it comes up often enough that I think I need to learn about it. What has "scalability" meant in people's experiences? What're the usual problems you have to solve? How do you learn to solve them? And how do you know if what you need is truly scalability instead of something completely different?
|
|
#
?
Feb 8, 2018 17:49
|
|
|
Pollyanna posted:So what's the deal with scaling? It's something that's come up often as a lot of companies I interview with say they're facing a bunch of problems in "scalability". From what I can tell, this basically means "we have so many users now that our systems are running like crap/we think we need to scale better", and can apparently encompass problems ranging from concurrency, to parallelism, to spinning up new AWS containers. IME: “When we had the interns build this stuff for us, no one thought about data layouts, partitions, or communication; now that we exposed it to the world it can’t handle more than a dozen concurrent users so we need an adult to fix it for us.”
|
|
#
?
Feb 8, 2018 17:55
|
|
|
Pollyanna posted:So what's the deal with scaling? It's something that's come up often as a lot of companies I interview with say they're facing a bunch of problems in "scalability". From what I can tell, this basically means "we have so many users now that our systems are running like crap/we think we need to scale better", and can apparently encompass problems ranging from concurrency, to parallelism, to spinning up new AWS containers. Get this book, it is an interesting read and is a great introduction to scaling systems and making them more reliable. I wish I had read it before I was interviewing. https://www.amazon.com/Designing-Data-Intensive-Applications-Reliable-Maintainable/dp/1449373321/ref=sr_1_2?ie=UTF8&qid=1518108854&sr=8-2
|
|
#
?
Feb 8, 2018 17:58
|
|
|
Pollyanna posted:So what's the deal with scaling? It's something that's come up often as a lot of companies I interview with say they're facing a bunch of problems in "scalability". From what I can tell, this basically means "we have so many users now that our systems are running like crap/we think we need to scale better", and can apparently encompass problems ranging from concurrency, to parallelism, to spinning up new AWS containers. It tends to be because the application architecture is built so as to scale vertically, that is by buying a bigger server, rather than horizontally by buying more servers. Usual culprits are write-paths through code. You can cache reads at various levels and have read-only DB secondaries, but traditional relational DBs tend to have a single primary node and there's only so big you can make a server. Sharding is the usual answer but it's not easy to do. Similar issue with writes to webservers since it requires you to have put at least a little thought into concurrency and DB locking. This is why the 2010+ generation of databases claimed at the time to solve everyone's problems because being "web scale" was the big issue of the day. They managed it with varying degrees of success but at least most modern data systems support true clustering to enable easier horizontal scaling. leper khan posted:IME: Yeah, see previous posts re the true role of a startup developer.
|
|
#
?
Feb 8, 2018 18:01
|
|
|
I've been working in a Linux environment since I started professionally coding 4 years ago and I've gotten substantially better with both bash scripting and the ecosystem in general but before applying again I'd like to dig deeper. The problem is books and poo poo don't really feel great to me? They all seem incredibly academic and I want like, a crash-course overview that Everything I've learned while on the job but I still feel like there are nuances and tools I should be stronger with. How is this something I can improve? I actually feel the same about SQL, especially since I've been doing data stuff, but that's a lot more boring to me. Anyone have suggestions?
|
|
#
?
Feb 8, 2018 18:06
|
|
|
When I worked at Experts Exchange, we had some pretty atrocious page load times. The architecture was so intertwined that, even with a profiler, it was pretty much impossible to figure out where stuff was slowing down. Occasionally, a slow bit of code or piece of SQL would float to the top of the list, where we'd fix it, but more often than not, it would look like the rendering stage was being slow, when it turned out there was some bit of lazily loaded data that would be hit during rendering and trigger a bunch of database queries. I finally started trying to convince management that, if they wanted the site to run better, they needed to give me the time to start rearchitecting things. That was when they went "Nahh" and laid me off. Well now the COO who laid me off is out on the street and I'm working on code that doesn't even have architecture! So who's laughing now???
|
|
#
?
Feb 8, 2018 18:11
|
|
|
CPColin posted:Experts Exchange .. atrocious page load times .. they went "Nahh" and laid me off That explains a lot of things. Thank christ for stackoverflow.
|
|
#
?
Feb 8, 2018 18:14
|
|
|
Pollyanna posted:So what's the deal with scaling? It's something that's come up often as a lot of companies I interview with say they're facing a bunch of problems in "scalability". From what I can tell, this basically means "we have so many users now that our systems are running like crap/we think we need to scale better", and can apparently encompass problems ranging from concurrency, to parallelism, to spinning up new AWS containers. When we asked this question of ops / arch people we wanted the response to start with a discussion about metrics and profiling before they talked about sharding, horizontal tier scaling, etc. You need to be able to measure poo poo and at least be able to eyeball bottlenecks from an "overhead" view before sticking your fingers into the poop.
|
|
#
?
Feb 8, 2018 18:47
|
|
|
JehovahsWetness posted:When we asked this question of ops / arch people we wanted the response to start with a discussion about metrics and profiling before they talked about sharding, horizontal tier scaling, etc. You need to be able to measure poo poo and at least be able to eyeball bottlenecks from an "overhead" view before sticking your fingers into the poop. Good to hear - whenever something vague like "we need to scale more!" comes up, the first thing I think is "what exactly does that mean, what problems are you running into, and if it's really a thing how bad is it and what is the best thing to do to tackle it".
|
|
#
?
Feb 8, 2018 18:59
|
|
|
CPColin posted:Well now the COO who laid me off is out on the street and I'm working on code that doesn't even have architecture! So who's laughing now??? High five no-architecture buddy. Scrum is awesome. 
|
|
#
?
Feb 8, 2018 19:19
|
|
|
Jose Valasquez posted:Get this book, it is an interesting read and is a great introduction to scaling systems and making them more reliable. I wish I had read it before I was interviewing. Totally gonna get this. Thanks! I wonder if this is why people are so intrigued by Elixir and the OTP platform. Maybe I can delve into that...would that be a good idea? Getting good at Elixir, Erlang, and OTP to make scalable and concurrent systems?
|
|
#
?
Feb 8, 2018 19:39
|
|
|
Pollyanna posted:Totally gonna get this. Thanks! I'm gonna say no. Learning Elixir and OTP is not a bad idea because it's getting kinda hot and could well be the new Ruby in terms of jobs for the next 10 years, but the concurrency offered by BEAM languages is so different to most stacks that you're not going to get a lot of use out of it except for when the whole team's really into it. People don't want snowflake apps in their systems even if it's the right tool for the job, and a highly concurrent distributed language is not much use without a highly concurrent distributed database to go with it.
|
|
#
?
Feb 8, 2018 19:50
|
|
|
Pollyanna posted:Totally gonna get this. Thanks! I really enjoyed https://www.amazon.com/Designing-Scalability-Erlang-OTP-Fault-Tolerant/dp/1449320732
|
|
#
?
Feb 8, 2018 19:55
|
|
|
Jaded Burnout posted:I'm gonna say no. Learning Elixir and OTP is not a bad idea because it's getting kinda hot and could well be the new Ruby in terms of jobs for the next 10 years, but the concurrency offered by BEAM languages is so different to most stacks that you're not going to get a lot of use out of it except for when the whole team's really into it. People don't want snowflake apps in their systems even if it's the right tool for the job, and a highly concurrent distributed language is not much use without a highly concurrent distributed database to go with it. Agreed. I love Elixir/Phoenix (and this seems to be where most Rails devs are going) but the job market for it seem to be nonexistent at the moment. Scalability is an architectural issue foremost and it's difficult to shoehorn it in to an existing codebase. If you're asked "how can we make this legacy code more scalable" then the answer is lol good luck. But if you were designing something new I'd start with microservices. It's great horizontal scalability but you pay for it in deployment complexity. e: LinkedIn has a good write-up on their horrifying scaling issues and why they developed Kafka The Phlegmatist fucked around with this message at 20:01 on Feb 8, 2018 |
|
#
?
Feb 8, 2018 19:57
|
|
|
The Phlegmatist posted:e: LinkedIn has a good write-up on their horrifying scaling issues and why they developed Kafka And this is also why Kafka is a properly distributed, clustered, self-healing data storage system.
|
|
#
?
Feb 8, 2018 20:07
|
|
|
leper khan posted:I really enjoyed https://www.amazon.com/Designing-Scalability-Erlang-OTP-Fault-Tolerant/dp/1449320732 Added to the list  Jaded Burnout posted:I'm gonna say no. Learning Elixir and OTP is not a bad idea because it's getting kinda hot and could well be the new Ruby in terms of jobs for the next 10 years, but the concurrency offered by BEAM languages is so different to most stacks that you're not going to get a lot of use out of it except for when the whole team's really into it. People don't want snowflake apps in their systems even if it's the right tool for the job, and a highly concurrent distributed language is not much use without a highly concurrent distributed database to go with it. The Phlegmatist posted:Agreed. I love Elixir/Phoenix (and this seems to be where most Rails devs are going) but the job market for it seem to be nonexistent at the moment. That makes sense - I don't want to limit myself to a specific tech in order to solve a particular problem. It would be good to understand the overall problem and solutions to it, though...guess I just gotta knuckle down and do my research. And yeah, I feared the worst when it turned out to be an architectural thing - that's not an easy problem to solve for pre-existing codebases.
|
|
#
?
Feb 8, 2018 20:07
|
|
|
Jaded Burnout posted:And this is also why Kafka is a properly distributed, clustered, self-healing data storage system. I'm trying to dig up the quote from my boss about rewriting Kafka Good Will Hrunting posted:Another problem though is that a lot of the things my manager wants to accomplish strike me as ridiculously over-engineered. He seems to want to engineer our own version of Kafka to use with Spark Streaming because Google Cloud doesn't have a managed Kafka service. I'm still struggling to understand why we need to do this as opposed to using another managed service they offer which could solve our problem (which they can - I researched this myself during downtime) and his answer to my proposition was "It's not Kafka and that's why we aren't using it". I'm currently over-engineering something as we speak because "using these objects is too high of an abstraction and unnecessary" (I wish I was kidding).. Good Will Hrunting fucked around with this message at 20:12 on Feb 8, 2018 |
|
#
?
Feb 8, 2018 20:10
|
|
|
Good Will Hrunting posted:I'm trying to dig up the quote from my boss about rewriting Kafka My time with Kafka was truly Kafkaesque. My client had me, as the only full time (Ruby) dev on the data team, learn Java (3 months), learn Kafka and expand their puppet library to support a kafka/zookeeper cluster (3 months), by which time they'd hired a permie Java dev for the team... and then the DAY after it went live in production they canned the entire project and we shut it all down. Cost them nearly £100k and they have nothing to show for it but some Avro schemas. SMDH.
|
|
#
?
Feb 8, 2018 20:17
|
|
|
Jaded Burnout posted:My time with Kafka was truly Kafkaesque. My client had me, as the only full time (Ruby) dev on the data team, learn Java (3 months), learn Kafka and expand their puppet library to support a kafka/zookeeper cluster (3 months), by which time they'd hired a permie Java dev for the team... and then the DAY after it went live in production they canned the entire project and we shut it all down. Sounds to me like they didn't know what they were doing or why.
|
|
#
?
Feb 8, 2018 20:22
|
|
|
Pollyanna posted:Sounds to me like they didn't know what they were doing or why. It came down to the good old "not showing enough business value to the higher ups" despite being on track as per a document I wrote them in month 0, so there must've been a breakdown in communication somewhere up the chain as to what the expected deliverables were and when.
|
|
#
?
Feb 8, 2018 20:25
|
|
|
Figures. If only the engineers could report directly to the higher ups, instead of trusting their livelihood to the managerial chain of command...
|
|
#
?
Feb 8, 2018 20:32
|
|
|
Jaded Burnout posted:It came down to the good old "not showing enough business value to the higher ups" despite being on track as per a document I wrote them in month 0, so there must've been a breakdown in communication somewhere up the chain as to what the expected deliverables were and when. At least the company took the (.avd)L and not your bank account.
|
|
#
?
Feb 8, 2018 20:38
|
|
|
While we're on it, can someone link me to some kind of Kafka vs competition article? I went over the Kafka site a few months ago because I had a feeling it might be a good fit for a problem we have based on half-remembered stuff I've read but couldn't be sure because their documentation was full of Kafka-specific jargon that I was having trouble mapping to things I'm familiar with like RabbitMQJaded Burnout posted:It came down to the good old "not showing enough business value to the higher ups" despite being on track as per a document I wrote them in month 0, so there must've been a breakdown in communication somewhere up the chain as to what the expected deliverables were and when. The breakdown was when they changed your timeline to make it look better to their managers.
|
|
#
?
Feb 8, 2018 20:44
|
|
|
Good Will Hrunting posted:At least the company took the (.avd)L and not your bank account. I need a mug that reads "I <3 contracts". Also you get my name out of your mouth when discussing IDL, I'm a web developer, I only write JSON, God's language, so it's all AVSC from me.
|
|
#
?
Feb 8, 2018 20:46
|
|
|
i'm a frontend engineer, the only language i know is react, dont expect so much from me jeesh
|
|
#
?
Feb 8, 2018 20:50
|
|
|
Munkeymon posted:While we're on it, can someone link me to some kind of Kafka vs competition article? I went over the Kafka site a few months ago because I had a feeling it might be a good fit for a problem we have based on half-remembered stuff I've read but couldn't be sure because their documentation was full of Kafka-specific jargon that I was having trouble mapping to things I'm familiar with like RabbitMQ I might be able to dig something up from the bibliography because their existing messaging is RabbitMQ, but for now the summary is: - Kafka topics are roughly analogous to RMQ topic exchanges, sort of - Kafka is kinda the reverse of RMQ; with RMQ you send messages to an exchange and they get routed to active consumers. If they can't keep up the exchange buffers, if it overflows you lose messages. If the consumer fails in a certain way you lose messages. If the consumer isn't there and the queue hasn't been created yet you lose messages. Whereas with Kafka you send to a node and it gets stored, then the consumers read at their own pace and can come and go as they please. - It's easier to change message formats with RMQ because there's no long-stored messages to deal with; you clear your backlog and make the change. With Kafka you keep messages around for a configurable amount of time, so if you change your mind about structure you have to deal with these older versions. They have some tech to help make this easier. Broadly speaking with RMQ you have to have your consumers up and running contemporaneously with your producers or at least very close to it, with Kafka the producers yell into the void and the consumers read it later. Kafka also has a more sophisticated ecosystem for stream processing applications.
|
|
#
?
Feb 8, 2018 20:55
|
|
|
Munkeymon posted:While we're on it, can someone link me to some kind of Kafka vs competition article? Check out PubSub, see if it fits your use case, if not use Kafka. Jaded Burnout posted:I need a mug that reads "I <3 contracts". "I <3 smart contracts" but the <3 is the bitcoin logo. Also AVSC is a pretty cool format, I used a ton of it but if I explain why I'll probably be immensely triggered.
|
|
#
?
Feb 8, 2018 20:56
|
|
|
Jaded Burnout posted:I might be able to dig something up from the bibliography because their existing messaging is RabbitMQ, but for now the summary is: Yeah, that sounds like it would have been a good pick. Good Will Hrunting posted:"I <3 smart contracts" but the <3 is the bitcoin logo. You misspelled 'Buttcoin' FYI
|
|
#
?
Feb 8, 2018 21:24
|
|
|
Good Will Hrunting posted:I'm trying to dig up the quote from my boss about rewriting Kafka Hmm yes this thing that's open source and used by thousands of companies in production... We need to rewrite it so that we can neglect to maintain a special forked version that will give us no end of technical debt. Also I am a project manager so I know what I'm doing. (this mindset is why we have Boost-but-not libraries in our codebase)
|
|
#
?
Feb 8, 2018 21:37
|
|
|
The Phlegmatist posted:Hmm yes this thing that's open source and used by thousands of companies in production... See also: our K:V store and our scheduler that we're using right now. The amount of push-back we've given is unreal. Does anyone give a gently caress and does my boss have the final say? No, and yes of course.
|
|
#
?
Feb 8, 2018 21:39
|
|
|
|
| # ? May 17, 2024 21:35 |
|
|
Munkeymon posted:You misspelled 'Buttcoin' FYI Is cloudcoin even a thing? Anyway, the proper name for bitcoins is Dunning-Kruggerands.
|
|
#
?
Feb 8, 2018 21:51
|
|