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.

«‹›2 »

pigdog: Apr 23, 2004; by Smythe

Finster Dexter posted:

But that sounds correct. Business sets the priorities. Product Owner is there to make sure the new priorities are reflected in the backlog, not to decide whether or not Priority A is more important than Priority B.

That's actually kind of exactly what PO does. The team does what the PO says needs doing, period (as opposed to CFO or whoever barging in). If a stakeholder absolutely requires the team to work on something, then she talks to the PO and the PO rearranges the product backlog. How the stakeholder manages to compel the PO arrange the backlog to reflect her priorities may vary. The business guy may feel it's very important for the team to drop everything and make a feature, but the lawyers may feel it's even more important to comply with some regulations by some deadline, the security officer may feel it's most important to fix a glaring vulnerability, etc. It's the PO's job to ultimately make these decisions for the team.

pigdog fucked around with this message at 23:01 on Jan 28, 2016

# ¿ Jan 28, 2016 22:56

Adbot: ADBOT LOVES YOU

# ¿ May 2, 2024 11:12

pigdog: Apr 23, 2004; by Smythe

ChickenWing posted:

Java devs: how do you feel about intellij idea? I'm working with Spring Tool Suite at work (Spring-focused eclipse distro) and I'm interested in seeing what idea has to offer, but I'm having issues finding out how to do all the stuff I'm used to doing in eclipse and I want to know if it's worth it or not.

It's fantastic, better, faster, more stable and more intelligent than Eclipse. IDE choice is a strong matter of preference of course, but in my current team where half the people use Eclipse and half use Idea, the Eclipse people had heck of a time importing a slightly more complex Maven project because it can only understand a single classpath per project or something. So that's one practical one-up.

# ¿ Feb 23, 2016 18:45

pigdog: Apr 23, 2004; by Smythe

Vulture Culture posted:

Our of sheer morbid curiosity, how do people in here feel about the #NoEstimates movement?

I think it shows promise. The point as far as I could tell is not to bother estimate hours OR points, but only count the stories. The premise is that on average, a team can do X stories per sprint at a greater consistency than estimating points per each story. Provided that the team is also creating the stories, the relative size of each story is relatively consistent, and calculating points on top of that is unnecessary.

By the way, for people working in Scrum teams, how many of you have also estimated the hours for task rather than simply estimating stories? Seems that Scrum community used to advocate estimating hours, but have these days moved away from that.

# ¿ Mar 12, 2016 19:58

pigdog: Apr 23, 2004; by Smythe

Skandranon posted:

This is assuming you're essentially breaking down your stories to some manageable and equal level of work. Sometimes stories are "As a Customer, I want a new next gen AAA FPS/MMORPG".

It assumes the team is breaking down the stories, which should be pretty standard practice. Customer usually just wants a thing, not dick around with stories.

# ¿ Mar 12, 2016 21:17

pigdog: Apr 23, 2004; by Smythe

Let me try and rephrase that. If a team can decide how big a story is (i.e. break "I want an MMORPG" down into regular sized stories for that team), then the number of stories done by the team over time ostensibly remains pretty constant. The premise is that the number of stories over time could be used for estimation with better success than having the team also estimate point scores for the stories, and use the average number of points per sprint, as is more common today.

# ¿ Mar 12, 2016 22:07

pigdog: Apr 23, 2004; by Smythe

Infinotize posted:

We have one of these and I cannot comprehend why we want to pay someone vast sums to read wikipedia articles to us.

There are tons of companies doing Scrum wrong or half-assedly. Why pay anyone money when you can read Wikipedia yourself?

# ¿ Apr 13, 2016 22:26

pigdog: Apr 23, 2004; by Smythe

FamDav posted:

Rather than attempting to measure uncertainty, you stick your head in the sand and pretend it's unmeasurable.

That's perfectly reasonable.

# ¿ May 23, 2016 07:22

pigdog: Apr 23, 2004; by Smythe

FamDav posted:

it isn't.

when you are trying to coordinate multiple teams across multiple disciplines over weeks/months, you need mechanisms that measure confidence of delivery. regardless, the way scrum does task estimation (or most anything beyond frequent iteration) is bad and can be done better.

All estimation is stupid, but at least Scrum has the developers themselves estimate by team consensus.

# ¿ May 24, 2016 20:52

pigdog: Apr 23, 2004; by Smythe

smackfu posted:

OMG, when agile meets an entrenched DBA group, so painful.

"Ok, you want some columns added to a table. That's pretty simple. Let's have a meeting to discuss the purpose of the columns. Then we will add them to the logical data model once you provide descriptive names for each. Then the other DBAs will translate that to a physical data model and then they will provide the SQL and you can submit a request to get it implemented. You do have funding, of course?"

That process has been going on for almost a month now.

And this is blocking a ton of stories of course, that are only waiting on final column names.

I hear you.

It's an organisatorial problem, though. The DBAs in such case have completely different goals and frankly don't give a gently caress about the work the developers are trying to accomplish.

# ¿ Jun 3, 2016 19:04

pigdog: Apr 23, 2004; by Smythe

Overseas coders who are actually good can ask for rates that are comparable to US developers, so price-concious companies hire people who are not them.

# ¿ Jun 3, 2016 23:18

pigdog: Apr 23, 2004; by Smythe

pigdog fucked around with this message at 16:43 on Jun 6, 2016

# ¿ Jun 6, 2016 16:39

pigdog: Apr 23, 2004; by Smythe

Gounads posted:

Has anyone actually gotten to the point where a non-developer is writing test specs in something like gherkin and then that becomes the functional spec? I hear fairy tales of that happening but have never even been close to it.

That's not quite how it should work. The business people, analyst, developer, and testers should work the specs out together, so that there is common understanding among all the involved parties about how the thing should work. The functional, automated spec form is a cool thing that also allows testing of that understanding to be automated, but the process of figuring it out and putting it on paper with everyone's input is really even more important. Not only common understanding, but importantly also shared responsibility, instead of "that's not what we wanted" or "but you said you wanted so and so".

# ¿ Aug 23, 2016 23:17

pigdog: Apr 23, 2004; by Smythe

rt4 posted:

What's the deal with microservices? Sounds like a good way to end up with an incoherent, fragmented codebase

That's not necessarily a negative. A major benefit of decoupled microservices is that the "ownership" of a service belongs to a particular team, who can use the technologies most suitable for the task, not just the ones that every dev in the organization is familiar with.

Just remember the rules:

1. Each service takes care of its own persistence - no sharing allowed. Physically you might share a single db or schema between them, but NO looking or touching other service's data. That would be integration by database, which defeats decoupling.

2. Never start with microservices ground up. Build a monolith first, then separate parts as needed and sensible. Practice good modular programming and you can have "microservices" within your application.

# ¿ Dec 20, 2016 12:44

pigdog: Apr 23, 2004; by Smythe

A very tangible benefit from microservices for many companies is that they can use geographically distant teams to develop different services. The teams are also focused on doing their part, and don't need to care quite as much about the domain and technology choices of others. Makes everyone's job much easier organizationally. That, as well as the scaling, hot deployments, etc.

# ¿ Dec 20, 2016 16:59

pigdog: Apr 23, 2004; by Smythe

Kaiju15 posted:

A nine person scrum just took twenty minutes. It felt like forty.

I think I just need to start calling these things "morning meetings" and lower my expectations.

Your team is too large.

# ¿ Feb 22, 2017 23:21

pigdog: Apr 23, 2004; by Smythe

Pollyanna posted:

So I'm getting reprimanded for relying on Moment.isValid(), a library function, to determine whether a date is valid. A prior solution had been to parse the date in Moment, then break the parsed date down into day/month/year and compare user input with that, but I figured that an equivalent and easier/shorter approach would be to just use the library's validation method, which we're already doing. Leverage what you've already got, right? Isn't that a major tenet of programming well? Instead, I'm being told off for not doing exactly what the director (my former team lead) wants.

Am I wrong in being really pissed off about this? It's a really minor issue but it feels like the guy's just looking for a reason to nitpick my work and I don't feel trusted to implement any solutions. I'm sick and loving tired of this rear end in a top hat breathing down my neck and questioning everything I do just to be a douchebag. Maybe I'm overreacting, but I can't stand working with this guy. Thank god I'm leaving.

Hopefully their preferred solution is packaged in a method in some common code at least? If so, then there could be a little bit of benefit of doing the same thing consistently everywhere in code.

At the same time, it's important to be free to say how you feel, and have an atmosphere of trust in the team. If you can't stand working with the guy, then you shouldn't.

# ¿ Sep 25, 2017 18:45

pigdog: Apr 23, 2004; by Smythe

Volguus posted:

From my personal experience, the scrum master is neither a team leader nor the person who only leads the standups. He/she has a bigger role, essentially being the bridge between the development team and the rest of the people (qa, project management, client representatives, etc.). The main role is to ensure that the developers have everything they need to do their work: a prepared and prioritized backlog for the planning meeting, answers to any questions that may come up, lead and prepare the demo meetings, the pretty charts and reports for the execs, etc. Leading the standups is but one (and a minor one at that) of their roles.
But yes, it does happen more often than not that the team lead takes on all those responsibilities. Or ... nobody does and everything is chaotic. A good scrum master can be the difference between a successful project and a failure.

Uh, a lot of that stuff there is the product owner's job. I can't remember if technically a PO may also be SM, but I'm pretty sure it's not encouraged.

# ¿ Sep 28, 2017 21:44

pigdog: Apr 23, 2004; by Smythe

Skandranon posted:

A more succinct way of putting it may be "I talk to the god damned PMs so the engineers don't have to! I have people skills! What the hell is wrong with you people?"

Yes. Except when it has to do with the product that the team is developing.

# ¿ Sep 28, 2017 21:53

pigdog: Apr 23, 2004; by Smythe

CPColin posted:

This same coworker is perfectly embodying the karma of my own rough start with Scrum. Yesterday, we were planning a sprint and got down to a item on the backlog that's a reasonable size, but isn't all that complicated. She balked at bringing it into the sprint, because she thought it was going to take longer than a sprint to finish. I pointed out that backlog items aren't supposed to take more than a sprint, so we should break it into tasks and then split it.

I showed off the acceptance criteria I'd already filled out, on the assumption that somebody would suggest just turning those into the tasks. It didn't really work out that way and the tasks became: 1) Figure out what data needs to be moved around, 2) Write the code that moves the data around, and 3) Write the controller for the job that'll wake up on a schedule and run the other code.

Okay, fine, not optimal, but I'll work with that. We started doing our estimate of hours and the same coworker said the middle task would take "days and days of work." I pointed out that tasks were supposed to be one-day affairs and she proposed breaking it into: 1) Design the code, 2) Write the code, and 3) Test the code. Agilefall!

(I finally managed to get the team to break out parts of the research and code that could be done separately, whereupon that coworker said, "Just put eight hours on everything!" So yeah, karma.)

This sounds like a pretty normal activity where you were able to slice the story thinner, which is good. Research/learning tasks are pretty reasonable to timebox. Not really seeing anything outrageous about what you were describing.

Regarding the ER thing it's not such a great idea to introduce an ORM in an existing system. Duplicate code is always bad however and the similar methods should be using the same code from a common wrapper or utility class or something.

# ¿ Oct 8, 2017 23:44

pigdog: Apr 23, 2004; by Smythe

Pollyanna posted:

Literally all of them, and it's a common complaint among the higher ups. Their solution has been to make everyone log their work down to the minute.

But why do the teams keep overcommitting? If it has any semblance of Scrum, then the teams themselves do the estimating. And the hard commitment is only to sprint goal, not every single thing taken from the backlog.

# ¿ Oct 10, 2017 19:55

pigdog: Apr 23, 2004; by Smythe

Mniot posted:

Product: Well, if I tell him you're only doing 3 features he'll be disappointed.
Devs: I guess we can try to work over the weekend.

why do that

# ¿ Oct 11, 2017 21:48

pigdog: Apr 23, 2004; by Smythe

Pollyanna posted:

They just banned WFH. Everyone is required to be in the office daily as of next week, no exceptions. This is "in order to increase our velocity and promote a one-team-one-culture concept". People asked how sick days and personal days are supposed to work and their response was that it'd be decided on a case by case basis.

Other than the puzzling thing about sick days, that's perfectly logical though. If people are working on the same thing as a team, then they need quick and effortless communication, so for best efficiency people need to be sitting physically close together, otherwise they're really handicapping eachother.

# ¿ Oct 11, 2017 22:10

pigdog: Apr 23, 2004; by Smythe

Mniot posted:

I mean, obviously you're right and it's a bad idea to do more work for less appreciation. Obviously. But it's pretty difficult to actually say no. Maybe everyone here is phenomenal at these things, but in my experience I'm one of the better engineers at saying no and I'm terrible at it.

Yes, we could all do a better job at saying no, but you would have a lot of good arguments against overcommittal. Past performance. Scrum rules and guidelines. Common sense. Also CEO showing that the devs aren't even that important to him.

Scrum like many other methodologies was designed for use in this kind of "hostile" environment, where devs don't trust the management not to pressure them, and the management doesn't trust the devs to perform. At least it would have made sense to stick with what Scrum explicitly prescribes on the simplest level. The covenant is that management gets a commitment (to sprint goal) from the devs, and in return the devs aren't bothered by management for the duration of the sprint. Communication from business goes through the product owner, who is the only person responsible for setting priorities for the team, and therefore responsible in the eyes of the management. While doing Scrum, you should have position of Scrum Master, who admittedly doesn't have any authority, but should be making an effort to fight for actually sticking to the rules, and seemingly did a pretty poor job in this case.

quote:

If you've got good communication, then it includes the developers saying "we need to work on this together. Let's all meet up in the office for the next week." If you don't have good communication, then having everyone sit in the same room while wearing earphones won't help.

Indeed, willingness to listen and willingness to speak (i.e. trust among the team) are also quite important.

Distance is always remains massive handicap though. Nobody can be arsed to answer "could you show me how to do X" or "why is this not working" or "I don't understand Z" kind of questions over Skype or email 20 times a day, but face to face it's no biggie. If people sit close together they can also tell if someone is having problems - even if they don't announce it. Overhearing teammembers (about the same product you're developing) is also quite important as it's "free" knowledge transfer between members. There's a reason e.g. XP is quite strict about it and people voluntarily follow: it yields success, and success makes everyone happy.

quote:

If we put all the engineers in a room and throw pizza in, magic happens, right?

It's genuinely one of the simplest and most effective things the managers could do. The fact that some devs get suckered into working just for the pizza shows how well it works.

pigdog fucked around with this message at 06:46 on Oct 12, 2017

# ¿ Oct 12, 2017 06:43

pigdog: Apr 23, 2004; by Smythe

Bruegels Fuckbooks posted:

It doesn't even really have to be multiple stored procs, you can soft code your DB logic by having, say, one stored proc that's a command name and arguments, and then having a table in the database with the command name, and the corresponding SQL that should be executed (don't sperg about this, you probably shouldn't do exactly this in your architecture but i'm using this example as a pedogogical tool.) The application can then just communicate with the DAL by passing command name and args, and the database can decide what actual SQL to execute should be.

The advantages of doing that are:

a) Fulltime dba can make modifications without changing source/building/deploying to customer sites
b) Easier to make your client backwards compatible because the older versions of the queries will be in db, not in client, so if a newer client connects to old database, since it communicates in commands, it knows to just do the old queries
c) Makes testing your DAL easier because you can just stub out these commands during integration tests by changing a single table rather than having to make a more complicated test fixture.

d) You can do fine-grained access and security controls and deny the user that the application uses all rights other than what's required to run the commands. That's a pretty legit usecase.

The disadvantaes of doing that are
a) The fulltime DBA's have other things to do than to coddle your application
b) The fulltime DBA's don't give a poo poo about your application and begrudgingly work on it as last priority
c) It's a pain in the rear end for everyone to develop, deploy and debug

# ¿ Oct 14, 2017 15:40

pigdog: Apr 23, 2004; by Smythe

lifg posted:

So I have a function that queries a database, and the whole thing needs to run quickly. It already has unit tests. But I want to make sure that future maintainers understand performance requirements.

Is it appropriate to add a performance unit test? Like �benchmark sub, fail if > 10 seconds�? One problem is that unit tests run on a shared server, against a shared database.

Normally whenever I fix a bug I add a unit test. I don�t know what the right thing to do when the bug is �slow performance.�

That's not a unit test. Testing performance is fine and good, but since it has dependencies on that shared server and doesn't need to be run as often as regression tests, I probably wouldn't put something like this it in the default integration test suite either.

There's nothing prohibiting you from commenting the code or writing whatever docs or messages to ensure the future maintainers understand these performance requirements. Whatever it takes.

# ¿ Oct 18, 2017 22:57

pigdog: Apr 23, 2004; by Smythe

chutwig posted:

My team is trying yet again to instill some form of agile process, so we borrowed a product manager from another team to help with our agile things like getting the backlog in order, running estimation sessions, being a neutral arbiter, and so forth. First thing they do is pour the dev and SRE projects in JIRA together into a single one.

WHYYYYYYYYY

I have long been an advocate of *ban rather than Scrum for SREs because it more accurately reflects the interrupt-driven nature of SRE work, plus I find the bookended nature of sprints to be artificial. Case in point is our current sprint (3 weeks long, which I think is too long) got laid out with tickets, we estimated them all, started the sprint, aaaaaand... I'm done with all my stuff on Thursday. 16 days to go and I'm already fishing around making more work for myself, which gets me mildly scolded by the product owner and PM. I can't pull more than like one ticket apiece from the other SREs because the majority of their tickets are to become familiar with and deploy systems I already know about, and if I take tickets like that from them it's only going to reinforce the silo of me being The One Person Who Knows About X.

Also, I really hate doing standups on video chat. We have a single guy on PST and we're all EST, so we have to delay our standups until like 1 PM every day and then it's 6 of us in the same row and one guy in California, so it's a festival of echoing mics and feedback the whole way through.

Given you're not even really developing software, then using Scrum for SREs sounds incredibly dumb.

Anyhow - the point of sprints is to have regular delivery and reflection [on the way the team is working]. All of this stuff you should really take up in a retrospective, which I'm assuming you do have. That's what they're for, to reflect upon and change the way people work to what works best in their particular situation.

# ¿ Oct 28, 2017 22:40

pigdog: Apr 23, 2004; by Smythe

Carbon dioxide posted:

I'm currently in my second job as a developer, and at both companies, Scrum was implemented as intended instead of half-assed and we didn't take it too strictly, as in we diverted from the guide when we discussed that doing so would help us out. The management left us alone to run it as we saw fit and/or actively took part in discussions about how to make Scrum work even better.

Unironically - way to go! Scrum is nice in the sense that there is a strict-looking and certified Scrum Way Of Doing Things that the devs may point at to prevent management and business side from screwing things up. On the other hand, internally, the Scrum guide is not meant for cargo culting, but to be taken as a starting point for what works best for this particular team. "What works best" being determined by retrospection between sprints.

# ¿ Nov 2, 2017 10:56

pigdog: Apr 23, 2004; by Smythe

Rocko Bonaparte posted:

Why have a desktop background as waifu when you can benchmark with waifu?

I'd hire Pollyanna if I was in a place to do so. We seem to participate in all the same threads. Actually I dunno if Pollyanna ever posted in the military history thread. Gotta check that. I'd just be afraid the organization would immediately turn completely crazy.

Hey, those are actually good utilities.

# ¿ Dec 2, 2017 23:43

pigdog: Apr 23, 2004; by Smythe

They must have quite bit of faith in their product, to face the ridicule of putting their animu wife in it if the product didn't perform. So it's kind of encouraging to be honest.

# ¿ Dec 4, 2017 11:20

pigdog: Apr 23, 2004; by Smythe

Ither posted:

When do you guys feel that method chaining gets excessive?

Like the following is fine
code:
foo.getBar().getBuzz()
But this makes my eye twitch
code:
foo.getBar().getBuzz().getFizz().getStudent()
And this makes me want to scream
code:
foo.getBar().getBuzz().getFizz().getStudent()
foo.getBar().getBuzz().getFizz().getTeacher()
foo.getBar().getBuzz().getFizz().setLocation(location)
It looks awful and its a pain to debug.

Law of Demeter. Does foo.getStudent() or at least foo.getFizz() make any logical sense? If so, add the chain behind it.

# ¿ Dec 5, 2017 11:22

pigdog: Apr 23, 2004; by Smythe

Portland Sucks posted:

I just looked this up and had no idea this exists which brought me to a larger question.

How do you navigate the process of getting familiar with and using more of the constructs in languages like C# that just seem to be endlessly long? I'm pretty fresh out of my undergrad, I'm the only developer in my shop (I work at a manufacturing company), and the only tutorials I can find on .NET seem to just cover basic OOP principals. Sometimes it feels like all of the "best practices" everyone is aware of online are trade secrets handed down orally from person to person. Where's all the good info hiding?

I don't know about .NET in particular, but for Java I found help from books, which explained more advanced and less often addressed features in detailed and accessible manner.

Books like Effective Java, Java Concurrency in Practice, Spring In Action etc.

# ¿ Dec 6, 2017 23:19

pigdog: Apr 23, 2004; by Smythe

Pollyanna posted:

It’s about how it reflects on me as an engineer. Having occurrences like these is a signal that I’m not as good as I should be, right?

YOU ARE NOT "GOOD".

You are not "bad" either.

What you, and everyone, is is being at a certain level at a thing (coding).

That level is not static, but you will improve it by learning (especially by doing) and experience, especially from failures.

It's a matter of static vs agile mindsets, which is an incredibly powerful metagame that drives our psychology, and frankly deserves its own thread.

Basically, if you have a static mindset, then you're either "good" at something, or when you run into a problem or criticism about something you think you're "good" at, then it must mean you're actually "bad" at it, and your focus shifts to hiding your "badness" and putting up an impression of "being good". And if that doesn't work, blame everything around you, and maintain that you didn't want the thing anyway. Etc.

INSTEAD, just accept that your skill level is dynamic and mutable. You may find that you're not as good at a thing as you thought, but you will improve if you put effort into it. Doing the thing and failing is not an indicator that you're "bad", but something that gives you experience in, and TRULY makes you better at the very thing. Without any need for pretending.

Don't waste time (outside of sales?) putting up a facade that you're "good", and heaven forbid someone finds out you're "actually" "bad". Accept that your skills are where they are, you don't know everything just like anyone, but find comfort in the fact that you CAN learn to do any goddamn thing better, by effort and experience and especially experience from failing.

Think of life as an RPG, where even if you lose a fight and don't get the loot, you still gain EXP and improve from that experience.

Edit: Similarly to whether you're "good" at development, you might ask yourself if you are physically fit? Say you're at 200 lbs. Compared to 700lb landwhales you're fit. As a Mr Olympia contestant, you're not. What you can do is compare your skill level to your own some time back. Am I getting "fitter", or better at coding, compared to where I was X months ago? It's the vector of where you're moving that's important - not the current level.

pigdog fucked around with this message at 11:16 on Dec 13, 2017

# ¿ Dec 13, 2017 11:00

pigdog: Apr 23, 2004; by Smythe

KoRMaK posted:

Good code is maintaible code. That means the important question is: what is maintainable code? Repeating myself here but, imo, its 1) obivous! 2)easily readable and understandable 3) can be altered to fix a bug without bringing down the whole house of cards 4) optional: hopefully has tests

Talking about repeating, number one rule should be No Duplicate Code.

I swear, some 70% of bugs I've had to fix stem from there being two+ separate ways of doing some thing, and a later change modifying only one of them as the changer was unaware of the other(s).

# ¿ Dec 13, 2017 11:25

pigdog: Apr 23, 2004; by Smythe

Rocko Bonaparte posted:

What did you all use before vim? I feel like I had used DOS edit way too much as a kid, and the Borland tool suite did nothing to help. I then flop into college, the UNIX intro book basically gave us a choice between vi and emacs. I struggled with both, but vi made me want to punch stuff. The rest is history.

My high school's computer class had old Unix terminals with poor terminal emulation for arrow keys, so vi was the best usable editor. Also, Nethack. It's also universally available in near any unix-like OS and usable over whatever SSH client, so it's useful to know in that regard.

Reasons to use it for serious work seem mostly about legacy force of habit though. I get using keyboard over mouse, but at least Jetbrains IDEs are surprisingly usable without needing to touch the mouse at all.

# ¿ Jan 4, 2018 14:33

pigdog: Apr 23, 2004; by Smythe

ChickenWing posted:

I want to know what these reasons are, because despite your repeated protests to the contrary I feel like they're mostly traceable to bad management.

With the ubiquity and ease of use of IM/video conferencing/screen sharing, someone being offsite should have near zero impact on their performance in a team. Even as a junior.

The communication bandwith between two people standing next to eachother, particularly if they have a whiteboard, is considerably higher than any other means. It takes considerably less effort to ask and pass knowledge that way. Passing knowledge, getting everyone on the same page, is the usually the main bottleneck in projects that involve a number of people working on the same thing.

If you ask the other dev about "hey do you know where the code is that does X" or "do you know why this here is like that" or "what if we did this like that", then when they are sitting next to you it's no big deal, but over an IM or email or phone it gets annoying real quick, so they refrain from communicating nearly as much. Even if the person is in the next room, you'd soon feel like a bell-end going back and forth to their office 20 times a day. In practical terms the physical proximity is hugely beneficial.

Especially important as a junior is that as a remote worker, not only do you have less idea of what the other project members are doing and where they're at, but nobody can notice if you are struggling or reinventing the wheel. Juniors doing remote work, it's just... nope.

# ¿ Feb 13, 2018 23:54

pigdog: Apr 23, 2004; by Smythe

B-Nasty posted:

Yeah, except that it is a pretty good indicator that it's a stupid fantasy to be clinging to.

I mean, pure, strict TDD (or Agile, take your pick) is theoretically sound and offers a ton of benefits on paper, but when you have the messy constraints of the real world mucking it up, its supposed value falls apart. Uncle Bob or whoever can come in and go all no true Scottsman on how you're not doing it right, but that argument starts to fall apart after it's been tried a number of times, and it continues to fail.

Everyone thinks they're smart enough to engineer it right this time, but it never seems to be the case.

Both TDD and Agile are quite successful in the real world and pretty much the default way of doing things at this day and age. True, neither is a magic formula. There is skill, experience and effort involved in getting it right (for any particular situation). Perhaps it's you whose viewpoint is no-true-scotsmanish.

# ¿ Feb 19, 2018 22:13

pigdog: Apr 23, 2004; by Smythe

Taffer posted:

How stupid of an idea is it to quit my current job before I have a new one lined up? I'm extremely miserable all the time and my work environment is really unhealthy. Also lining up meetings, interviews, practice for interviews, etc, is really hard when you're also working full-time. Apparently it's common at many places to have interviews that are 2 hours or more.

I was advised by some people with good intentions to wait, but I don't know if I can.

It's a bad idea. Being between jobs will eat your savings quickly, you're in a worse negotiating position, and who knows when can you actually start working even if you get a job offer right away. In short, tried it once, wouldn't recommend.

# ¿ Feb 27, 2018 23:57

pigdog: Apr 23, 2004; by Smythe

Ownership also means sovereignty and not being limited to other, distant, possibly dumb people's decisions in that particular segment. Dealing with people whom your project is dependent on, but who have no interest in your project's success, is the worst.

# ¿ Apr 12, 2018 10:00

pigdog: Apr 23, 2004; by Smythe

BaronVonVaderham posted:

My team is the absolute best at sprint planning.

I'm troubled by the fact this chart even does have Saturdays and Sundays on it.

# ¿ Apr 18, 2018 22:34

Adbot: ADBOT LOVES YOU

# ¿ May 2, 2024 11:12

pigdog: Apr 23, 2004; by Smythe

necrobobsledder posted:

They�re gray for a reason?

Think of them as Chekhov's gun.

# ¿ Apr 19, 2018 08:24

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

«‹›2 »