Working in Development: Leaving sounds like a great decision.

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > Working in Development: Leaving sounds like a great decision.

return0: Apr 11, 2007

Asymmetrikon posted:

Well, source control isn't "fast" enough, you see. Clearly the best way to write code is to make a change to your file, FTP it to the production server, and cross your fingers that nothing breaks. Instant feedback!

Thankfully, my team only has to interact with that stuff peripherally; we have a Kallithea HG server that we store our repos on, and the only trouble is when we need someone on one of the other teams to make a change to a system we interact with.

Also, it's Coldfusion web dev (them, not us; we do Python). I feel that explains a fair bit, frankly.

Even if you wanted this, why not just push to a git repo on the box, or push to like GitHub and have a cron to pull the production branch? Pushing a bunch of diffs to SCM and having it automatically show up on production is like literally easier and less error prone than scp-ing every changed file manually.

# ¿ Nov 28, 2015 14:24

Adbot: ADBOT LOVES YOU

# ¿ May 3, 2024 02:55

return0: Apr 11, 2007

DigitalRaven posted:

Easier to set up your own remote that auto-pushes to live whenever someone pushes to it. That way changes go live immediately and you only need one pull as part of the build for the production box, so it's more robust when you nuke and rebuild.

Well, yes, exactly.

# ¿ Nov 28, 2015 15:34

return0: Apr 11, 2007

HardDisk posted:

And then your special snowflake application has to sign up users slightly differently from the method that the plugin supports and either you have to scrap the plugin and roll your own method anyway, or try to kludge what you need in the plugin and ending up with a complete mess, or the plugin is so generic and full of required configuration that it's barely worth keeping it.

Devise is pretty legit tbh

# ¿ Jun 30, 2016 22:01

return0: Apr 11, 2007

If I had to work at a place that used SVN, I would checkout the SVN repo into a Git repo and work in that.

# ¿ Jul 21, 2016 21:13

return0: Apr 11, 2007

Am personally hoping it's the bubble bursting as liquidity dries up with rising interest rates, so we all face horrible hardship.

# ¿ Sep 14, 2016 19:19

return0: Apr 11, 2007

Might be a language barrier but what do you mean scream/screaming?

The connotations of that here are always to do with pain, anguish, or emotional distress, but I guess you guys mean more aggressive/confrontational shouting and bullying. Lol if someone sticks around for that.

# ¿ Sep 30, 2016 20:07

return0: Apr 11, 2007

necrobobsledder posted:

Shouting or yelling may be a more appropriate word with more restricted meanings.

Last job I had I was a few steps down from a newly hired executive that seemed to have explicitly hired to be aggressive and to push people around because so much of the company was too lax and nothing got done as a cultural value. Work-life balance doesn't mean that everyone instantly clocks out at 5:30 pm unless your datacenter is literally on fire by my standards, but that's what it seemed to mean for most people.

In my contract I am salaried based in a 40 hour week, I'll stay more maybe but it has to be give and take, I'm not just going to do it for free. Why would anyone?

# ¿ Sep 30, 2016 21:10

return0: Apr 11, 2007

Personally I would nag. Mention it at the stand up every day, harass on a public slack channel, etc.

# ¿ Oct 3, 2016 23:47

return0: Apr 11, 2007

Cancelbot posted:

To contrast with PR chat, where I work is hard on the single branch approach:

- We use mercurial, everything goes into default
- Every commit must be releasable, if it is not you use a feature flag
- Nearly everybody pairs, we're experimenting with mobs

Does anyone else do this?

We do every commit goes to master and deploys live for pretty much everything. We do synchronous code review at point of commit, it is illegal to refuse if asked to review and takes priority over everything except critical service outages. We don't pair much but do sometimes.

# ¿ Oct 5, 2016 00:07

return0: Apr 11, 2007

AskYourself posted:

Wtf so you go prison if you say no ?

Are you allowed to say that you will review it but just need a few minutes to wrap your mind up ? What if you really need to go to the washroom you can't say no ?

If you need to go to the toilet or make a coffee or spend two minutes wrapping up then that's obviously fine, the point is you cannot defer peer review and must do it immediately. It works pretty well, and is quite well aligned to a one-piece-flow / kanban philosophy.

revmoo posted:

What do you guys think about "coding projects" in order to secure a job? I've done them once or twice in the past and ended up hating the actual job once I got hired and kind of swore off doing them again. I'm not happy at my current job so I've been interviewing. I've already done two levels of interviews with this potential company and they want me to do a coding challenge that is suspiciously complete. They want me to build an app:

- That allows user registration
- Users can post
- Users can comment on other's posts
- Users can edit content
- Users can download an export of all their content

This is all pretty straightforward stuff, but to do it right involves basically building a complete app and then handing it over. I have no problem with stuff like Fizzbuzz, but this seems like too much. I either half-rear end it and make myself look bad, or I spend 2-3 days building it right which does not seem like a good use of my time. I get paid for this kind of thing after all. Plus the requirements almost give me the suspicion that they could be using my work for commercial use after I hand it over.

I liked the company, but this seems like a bit much. I asked if doing the project was contingent on an offer and the response was basically "do it and we'll let you talk to the CEO about it." I'd be a whole lot more confident doing the work if we had solid terms worked out but they're unwilling to do that.

I'm leaning towards telling them to gently caress off. I have other prospects and they already had the chance to quiz me in the technical interview. I even sent over code samples for them to review. But maybe I should just do it? I dunno. My gut tells me I shouldn't but maybe I'm just being dumb and should get over it and throw the app together.

That is too much. At my place we have an exercise that is as small as possible while still being a somewhat interesting problem that we can derive some useful insight on how people code, how they research, etc. It's an optimisation problem with a trivial polynomial solution and a slightly more complex (but still straightforward) linearithmic solution with an appropriate data structure. It should take an hour tops and a succinct python solution fits on a single page of code.

No way would I write a full web app that takes 8 hours.

Pollyanna posted:

Stuff about rejected PR

In a place like this, what happens when a PR is rejected? Do you get concrete, actionable feedback on what to change, or is it vague? What happens if you disagree with the PR feedback? In a synchronous communication the developers would just talk face to face about it and agree what to do, but in a more passive asynchronous and impersonal process I can imagine it being much more difficult.

return0 fucked around with this message at 20:11 on Oct 6, 2016

# ¿ Oct 6, 2016 19:53

return0: Apr 11, 2007

Iverron posted:

Would you mind sharing the exercise? If not that's cool.

We haven't had the best experiences hiring lately and the exercises / questions our leads are asking aren't getting the job done. I'd rather transition to something like what you're describing.

Sure. We give the candidate two files full of 2D points (one tiny and one big), and ask them to write a program to find the point furthest away from any other point. The files are just lines of the form:

code:

name x y

The instructions provide the correct answer for both files, so the candidate can verify their solution. They can use whatever language, but we state we expect the program to be better than O(N^2) (and ideally be fast in practice). We also ask that the program read input from standard input and write the point name as output to standard output.

There is some narrow overlap with the domain we work in, but really we find it's a nice enough exercise because it requires a little bit of research if people are not familiar with spatial data, and requires a little bit of implementation. It's nice because it should generally not take that long, and it also gives us something to talk about with the candidate.

Not sure if that would be appropriate for you to use, but I'm sure there are equivalents for your domain? I think we could easily switch to a different but similarly scoped exercise and get the same benefit.

# ¿ Oct 10, 2016 23:47

return0: Apr 11, 2007

It's a nearest neighbour problem, it wants the point with the highest nearest neighbour distance value. There are a bunch of solutions that for non pathological input will be between nlogn and n^2. Yes, the work involves quite a bit of geospatial data manipulation.

# ¿ Oct 11, 2016 08:22

return0: Apr 11, 2007

necrobobsledder posted:

It's not cost-effective whatsoever to build out literally 50+ database instances

Why not?

# ¿ Dec 21, 2016 08:38

return0: Apr 11, 2007

Pollyanna posted:

Currently ongoing. Still on the "find places and do their phone screens" stage. I'm actually having trouble finding jobs to apply to, or at least ones that I like - I mostly rely on AngelList and StackOverflow, and tips from personal contacts. It's certainly nothing like the "OH MY GOD THERE'S A HUGE DELUGE OF ENGINEERING NEEDS EVERYWHERE!!!" thing that everyone claims, but maybe that's just my pickiness.

Maybe try a big tech co, like Amazon/Google/FB?

# ¿ Jun 2, 2017 15:31

return0: Apr 11, 2007

You should apply to Amazon, it's actually cool and good.

# ¿ Jun 8, 2017 22:28

return0: Apr 11, 2007

I can only speak to my personal experience, but I'm glad I didn't put too much weight into the Amazon horror stories before joining. I've worked in two offices, in both there have been sane working hours, smart and respectful colleagues, and good high-end equipment.

For an organizational of it's size, I've found the autonomy teams get over product decisions, tech choices, and working practices pretty incredible. There is oncall rotation, but I assume there is the same at Google/FB. I've personally had one out of hours page so far this year.

Perhaps it has changed significantly over the last few years? I should mention I haven't worked in Seattle (or indeed the US).

# ¿ Jun 13, 2017 07:28

return0: Apr 11, 2007

Volmarias posted:

Also, if you work for a subsidiary they get quite a bit of control over their own destiny, like being able to offer free coffee instead of requiring employees to pay for it.

This is not true, you don't have to pay for coffee or snacks etc. There aren't excesses like masseuses or gourmet lunches, but that's cool with me.

I should stop defending it now, but didn't want misinformation to discourage anyone itt from considering it.

# ¿ Jun 14, 2017 00:04

return0: Apr 11, 2007

BabyFur Denny posted:

Apache Spark is the PHP of big data applications. On so many levels.
- everyone is using it or used it at some point
- it's full of bugs, quirks, and surprises
- it tries to do everything, but
- it never is the best solution for the particular problem you are trying to solve
- it's poo poo
- but we're gonna be stuck with it for the foreseeable future.

Hmm I dunno. What's better at general etl/analysis than spark?

# ¿ Sep 7, 2017 18:07

return0: Apr 11, 2007

I use Spark extensively at work to process decent sized datasets, and have found it pretty good tbh. One difference is I've used the Scala API exclusively, and haven't touched the java API. I don't recognise your comments about map/flatmap not taking lambda from my experience, for example. I have read anecdotally the Scala API is more consistent.

I've used Hadoop for similar batch ETL in the past (with python over Hadoop streaming) and find Spark to be light years better. Maybe try Scala?

# ¿ Sep 8, 2017 07:21

return0: Apr 11, 2007

ultrafilter posted:

need better than acceptable performance

Hmm.

# ¿ Sep 11, 2017 00:38

return0: Apr 11, 2007

The Google C++ standards historically were pretty weird, are they better now?

# ¿ Dec 28, 2017 22:28

return0: Apr 11, 2007

It is kind of annoying when you�re pairing with a slow typist though.

# ¿ Apr 29, 2018 12:23

return0: Apr 11, 2007

JawnV6 posted:

Abstruction

Nice!

# ¿ Jul 25, 2018 23:38

return0: Apr 11, 2007

Shirec posted:

Question for y�all. I�m looking to develop better coding habits and also find a way to distinguish myself from the pack while also helping others (easy right?). There�s been a lot of talk about how poorly my company�s code is documented and understood because the code base is so large.

I figured one thing I could do to at least help a little is start putting way more comments in to explain the little bits I�ve touched so far (I�ve got one bigger PR in the works at the moment). Right now the code base is very hit or miss with it.

Or is this a giant mistake? If not, any preferred type of comments or styles?

I try to avoid writing code comments where possible. My observation is that if I'm looking at a heavily commented code review, there is a decent chance that the code is bad.

Exceptions to this are inline links to external documentation that describes the overall technical design if interesting, as well as non-technical documentation that describes the business process the code is modelling. If these documents sound like they'd be useful but they don't exist, write them in collaboration with whoever knows the business goal! If you have nowhere to put them, like a wiki or whatever which non-devs can read, stand one up.

Imo to improve your code, get your team to:
1. Emphasise writing testable code.
2. Don't hard code dependencies.
3. Write tons of tests.
4. Keep things (classes, functions, modules, whatever) small.
5. Don't have long lived development branches.
6. Continuously deploy everything with good infrastructure to make deployment and rollback dirt simple.
7. Have excellent monitoring.

# ¿ Aug 24, 2018 20:28

return0: Apr 11, 2007

A reduced scope by making the functional unit smaller can often clarify by reducing the complexity of the surrounding context as much or more than literally changing the name, often with other beneficial effects.

# ¿ Aug 24, 2018 23:38

return0: Apr 11, 2007

To be fair, I think they reasonably assume anyone running a weird NAT punchthrough HTTP proxy development tool will ensure they isolated from the real internal corporate network.

# ¿ Sep 9, 2018 02:31

return0: Apr 11, 2007

Working on master is actually cool and good, and preferable to long lived feature branches.

# ¿ Dec 16, 2018 02:07

return0: Apr 11, 2007

No they can�t; not beyond a certain scale.

# ¿ Jan 1, 2019 04:22

return0: Apr 11, 2007

I disagree. There are clear operational wins to be had at scale by breaking a monolith apart in any circumstance where different logical parts of the monolith have different functional characteristics. For example, a user identity service component which is called very frequently contrasted with some rarely called leaf system; a highly compute intensive component contrasted with an I/O intensive component; a subsystem with a data model best suited to a relational DB contrasted with another using a document store, etc. Isolation has benefits here.

# ¿ Jan 2, 2019 11:36

return0: Apr 11, 2007

Vulture Culture posted:

I'm not arguing that there are no benefits to using a microservice architecture, especially operationally—running production services is hard and there's lots of compromises required to deliver a great user experience on the backend. I'm arguing against your assertion about non-microservice development models being inherently more of a maintenance burden when a) it hasn't been established whether or how these actually improve modularization in practice and b) nobody even understands how gracefully a 150-microservice business service will transition into a legacy operating mode 15 years down the line.

My initial assertion was that the following is false:

Bongo Bill posted:

The structures that make it possible for microservices to ever be economical can also be applied to monoliths to make their maintenance more tractable for longer.

We've established one such 'structure' that can be applied to a microservice architecture that cannot meaningfully be applied to a monolithic architecture; significant divergence in operational requirements by different parts of the system necessitating different hardware or persistence layer implementations. These divergences in operational requirement manifest at large scale (because at small scale anything reasonable works).

bob dobbs is dead posted:

clear operational losses to be had at scale by breaking a monolith apart, where you have to put in backpressure, where you have to log the poo poo outta everything to get worse logging than what you have with the monolith and then you gotta monitor the poo poo outta everything to get worse monitoring than what you had then you still have to go traipsing through the zoo of services to find wtf it is that's the root cause of breaking, etc etc

I mean, don't do it for no reason, but don't pretend there is never a reason.

# ¿ Jan 2, 2019 14:44

return0: Apr 11, 2007

Polio Vax Scene posted:

Our company has an API server that can receive status updates from a third party.
We're seeing some status updates in the logs, but not all of them.
They insist they are sending us all the status updates.
What would be the best way to prove them wrong? It is a RESTful API with basic HTTP GET calls for the status updates.

Is the status update content in a request body, or query string, or some other means? Is your caching header correct?

If it�s the body then perhaps a proxy or cache on route is responding, since it�s historically valid to assume a GET body has no semantic meaning (see https://groups.yahoo.com/neo/groups/rest-discuss/conversations/messages/9962?guccounter=1).

You should use another HTTP verb anyway, but definitely don�t rely on GET bodies.

# ¿ Jan 13, 2019 03:04

return0: Apr 11, 2007

That�s what I was alluding to by �Is your caching header correct?� but worth being specific I guess. I agree changing the verb is the right call.

# ¿ Jan 13, 2019 20:03

return0: Apr 11, 2007

Cancelbot posted:

Right now our company is getting a hard on for value stream mapping, but I don't get why they are repeatedly trying to apply manufacturing principles to software engineering? I'm not saying software is un-plannable or the processes cannot be improved. But tickets/build artifacts/whatever isn't "inventory", we aren't building 10,000 widgets an hour. If they want to compare it to manufacturing; then it's a weird shop where every customer that comes in orders a very specific customisation every two weeks that only serve to make your widget ever larger as time goes on.

There's definite & clear processes where value stream mapping/lean manufacturing does fit; oddly enough it's the dumb easy-to-automate poo poo, but no we also have to do it as a one size fits all map that applies to stakeholder requests.

I've seen one teams value map and their prioritisation lead time is over 12 months because these things wildly vary based on stakeholder mood, current pressures, is it windy, etc. It is not a manufacturing process.

I like to use some of that vocabulary (particularly inventory) to refer to work where the output the value delivered by the work is withheld until long after the work completes. This is usually by one or a combination of:

A desire to cliff-edge work in order to increase its perceived impact, by announcing the launch many features at once.
A pipeline where each stage is catered for by as specialist, where one stage is significantly slower than the others, causing a backlog of invested effort by the other stages. This is typically design & art roles, BI analyst research, etc, which depend on contended development resource to execute.
A technical plan for development where means that no part of a feature can be launched until all of it completes; i.e., a lack of incremental delivery. The parts which could have been separated and delivered early while work is ongoing on the rest is 'inventory' until it's released, it's an investment with unrealized value.
A lack of experimentation leading to commitment of resource on an expensive development effort which doesn't succeed.
An over-eager PM or QA who generate thousands of issues & tickets, needing triaged and maintained despite nobody realistically being able to work on them.

I agree it's not a great fit in terms of the solution space, but there's an argument that the same principles apply. Here's a (long) read that does a decent job of articulating my feelings: https://apenwarr.ca/log/?m=201712.

# ¿ Jan 19, 2019 21:58

return0: Apr 11, 2007

Protocol7 posted:

It's a good thing I might be getting another job because today, the idiot QA on my team tried to insinuate that the QA test server had issues. The reason was that the CI build was failing, as the build server is currently missing a third party license. Easy fix, just ask DevOps to install the new license.

And yes, our builds don't go anywhere until CI runs to green. The QA test server hasn't received a new build in a week. He knows to check these things.

The real cause - his poo poo is misconfigured on that specific server.

Sounds like the QA test server had issues (staleness, due to an upstream deployment error, due to a misconfigured CI). Do developers not check that builds get through CI, or get alerted to failures?

# ¿ Feb 23, 2019 08:55

return0: Apr 11, 2007

Doom Mathematic posted:

The other half of the problem with that analogy - which I actually really like because of how instructively bad it is - is that it's impossible, or at least hopelessly circuitous, to iteratively turn a skateboard into a bicycle or a bicycle into a car.

The notion is that you might cheaply learn they don�t actually want a car without actually building one.

# ¿ Apr 12, 2019 23:42

return0: Apr 11, 2007

Lord Of Texas posted:

This but unironically.

How do you know which individuals need support without tools (code review/pr, git blame, etc) to see who needs help and how much the need it?

# ¿ Jul 27, 2019 15:22

return0: Apr 11, 2007

Protocol7 posted:

Bonus points for someone replying to an email far back in the chain hours after the email has already been replied to, splitting the email chain into a fork of unintelligible thoughts.

Replying to correct an earlier error or provide relevant information is desirable. The bad part is how crap email is.

# ¿ Aug 13, 2019 00:21

Adbot: ADBOT LOVES YOU

# ¿ May 3, 2024 02:55

return0: Apr 11, 2007

Pollyanna posted:

Today I got a review on my code saying that I shouldn�t be creating multiple classes for a particular solution that has several problem domains (and is split up accordingly) and should instead keep all the logic (CSV generation, queries, encryption, uploading, etc.) in one class and file because it�s easier to understand. I specifically split it up like that so that each piece would be easy to understand on its own, and you didn�t have to keep the whole thing in mind when working on it, because it�s a highly business critical thing that touched several parts of what we do and has a particularly heinous handwritten SQL query that I wanted to sequester.

I don�t know how I feel about this, exactly, but I know I don�t feel great about it. gently caress it, man, whatever works.

Personally I would tell the reviewer to go gently caress themselves.

# ¿ Oct 19, 2019 14:44

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > Working in Development: Leaving sounds like a great decision.