|
I think you're overthinking it. Just approach it pragmatically from what you need: "Coworker, are you going to be in on Monday? I was thinking of refactoring the blah controller, but I wanted your input." or, "Manager, do you know if Coworker is going to be in today? I know he's usually out Mondays and Tuesdays, but I'm blocked until he returns on the blah controller." If he has some medical / family / strange PTO arrangement, the manager should be aware and can let you know: "Oh, Coworker is going to be out M-T for the next five weeks. Do the best you can, and he will look at it when he gets in Weds." If he doesn't have an arrangement, you've let the manager know that your coworker is out regularly and it's affecting your work. It's not throwing him under the bus to relay facts - if he is indeed no-call, no-showing, you're not required to cover for him.
|
#
¿
Oct 23, 2015 14:50
|
|
|
|
| # ¿ Apr 26, 2024 05:56 |
|
|
Vulture Culture posted:
Thanks for articulating something I've had a problem with on teams I've been on. I'm a worker bee but have occasionally done some low-level project management with middling success, mostly by deliberately avoiding the worst practices I've seen. Thanks for the book suggestions too. I got a copy of Making Things Happen - it's hard to find books about management that don't dissolve into business-y self-help. Lately, I'm back to being an individual contributor. The most frustrating aspect is dealing with a group of smart, motivated people who insist that they don't need project management - and then the project dissolves into a million competing features and premature optimizations. Is that sort of thing salvageable by managing up, or should I just find another project? vonnegutt fucked around with this message at 16:20 on Feb 14, 2016 |
|
#
¿
Feb 14, 2016 16:12
|
|
|
Vulture Culture posted:Competing features and premature optimizations aren't management problems, necessarily, as much as communication problems. Self-organizing teams can avoid redundant or incompatible work, but it requires people to actually coordinate ... Great advice all around. I always want to make sure I'm paying attention to the larger picture, and speak up if I think something is being overlooked, but in this instance I don't think I really have the clout to make any improvements.
|
|
#
¿
Feb 15, 2016 01:34
|
|
|
I wouldn't worry. If you can prove that you are just as productive, nobody will care. I've had two types of coworkers who worked from home (WFH) frequently - the introverts and the overextended. The introverts did fantastically. You knew that when Jane stayed home to work, it was to knock out a big, hard task, and that she'd be back in the office for code review and bugfixes. These coders were usually on a standard schedule - in-office Monday, Weds, Fri, at home Tues, Thurs. The overextended tended to say they were WFH whenever they had prior conflicts - the cable guy coming over, babysitter suddenly AWOL, feeling "stressed out" - they didn't produce much of anything nor were they very responsive over email or instant messenger. It was very evident that they were just using it to avoid having to take vacation or sick leave, and they were known to be flaky and were somewhat resented for it. "Performative work" is bullshit you do to prove you are doing actual work, and it is stupid, but very useful, esp if your manager is a non-coder. On any day where you WFH, make sure you tell people exactly what you're going to achieve, and show them after the fact. This can be as simple as "I'm going to work on a big chunk of the email feature" and then coming back and pairing with Mark on said email feature. Be responsive on email and instant messenger from 8 - 5 (or whatever), and announce when you'll be offline - "Going to take lunch, back at 1:30" / "Done for today - see you tomorrow" / etc.
|
|
#
¿
Jun 9, 2016 13:34
|
|
|
Pollyanna posted:
That was kind of my point - showing how productive you are is key. The overextended coworkers who thought they would be productive working from home with a sick kid were usually ...not. Or at least not as much as they would be in-office. In those cases, it would be better to say you're taking a day off and will try to work a half day if possible. The resentment came from people acting as if they could put in a standard 8 hours, including being available by chat and email, and then clearly not achieving that. It doesn't sound like your office has any kind of official policy in place, which makes it even harder - then you're relying on people's opinions and impressions of your productivity rather than actual work completed. In your position, I would be extra diligent to make sure your WFH days were well documented work days, however that works at your company.
|
|
#
¿
Jun 10, 2016 00:27
|
|
|
Analytic Engine posted:Front-end programmers: How did you develop your sense of design style? I've gotten pretty good at coding and data visualization for web development but my visuals are still dull and boring. I know how to identify bad style (so it's not quite programmer art) but I'm still a babby designer. It would be great to know a few stories from successful people. I came from a print design background, but I think the general process still applies. This is where a site like Dribbble or Behance comes in handy, or even Pinterest. Here's what I've done in the past: - Collect screenshots of design that appeals to you. Don't limit yourself in any way, just grab anything that catches your attention. This should be ongoing. - Every now and then, look through your collection of inspiration and start mentally categorizing similar items. Eliminate any that no longer look good to you. - Analyze similar items for what makes them similar and what you like about them. Do they all share a similar color scheme? Do they all use whitespace the same way? Are they focused on a similar typographic approach? Try to figure out what that key idea behind the style was, and how they made it work. - Reimplement a style you like based on the analysis you just did. Don't copy directly - try to combine the best elements of three or four similar approaches. - Shove up your own screenshots on a portfolio site. This is super important, it's how you start to see common themes in your own work.
|
|
#
¿
Jun 17, 2016 23:30
|
|
|
Doghouse posted:The code base seems kind of sloppy and disorganized, they use stored procedures for everything, and the whole thing just seems so blah. Every small change seems to require slogging through a lot of spaghetti code, but maybe I just don’t understand the code base well enough yet, and I realize that every job and company is going to have its issues. I certainly can’t jump jobs again, at least for couple of years, so I’m just going to stick it out and see how much I can learn. I would also welcome advice on how to deal with this type of codebase - in my case, it's relatively new, but very very poorly architected and untested. If it were just me and I had 3-6 months, I could probably refactor it into something more legible, but I'm working with two devs that are new to the framework (and in one case, language).
|
|
#
¿
Jul 19, 2016 22:38
|
|
|
necrobobsledder posted:Refactoring old or unfamiliar code? Pick up this book if you haven't done it before. I try to understand the codebase as much as I feel like I should to be able to be productive, and one of the easiest ways to get acclimated to a codebase is to write or fumble with existing tests. If you don't have any tests, you can't break anything, after all. If you're modifying test code, then you should start getting a feel for trivial cases then edge cases as you modify something you don't think you understand. Almost nobody is all that productive with a codebase they haven't had a hand in for at least a week in my experience Thanks! That makes a lot of sense, I've always worked on heavily tested codebases so finding out that this one ...didn't...have...any really raised some alarm bells. My first reaction was to set up a testing framework, so at least it will be possible to backfill the tests, even if it takes forever. I guess my main issue is, I don't know how to communicate to the other devs that this all needs to happen - the ones on my team are on board, but the team that originally started the project are the ones who didn't think tests were important and are fine with the status quo. Is this something that can be fixed or is this a sign to start updating the old resume?
|
|
#
¿
Jul 20, 2016 14:19
|
|
|
necrobobsledder posted:
Just to be clear, when I said I set up a test framework, I meant I added a preexisting test library and a config file and wrote some example tests. I'm not crazy enough to try to roll my own! I took a look at one of Michael Feather's talks about working with legacy code last night, and it makes sense. Don't start changing existing code immediately, add any new features properly (follow language and framework conventions, test thoroughly) and isolate them from the legacy code base, and start writing tests to make sense of what's going on. The codebases I've worked on have been fine up to this point, but I have never seen anything like this. Almost all the code is in one file (in a framework that highly recommends against this) there's dead code all over the place, both commented out and not, and the version control consisted of one massive commit done about once a month.
|
|
#
¿
Jul 21, 2016 21:47
|
|
|
necrobobsledder posted:
exactly this. We had to onboard a new pair to one of our projects and this was exactly the process we used. We didn't even have a typo to fix, we just had one of them find a random h3 and make it an h4, and then had the other guy switch it back. The goal was to make sure they each had access to the repo, were able to pull it down, run it locally, make changes, and push them up to source control. After that we talked through the db schema and some of the weird business stuff the project has to work around, and that's pretty much it. However, I'm becoming less and less surprised by the amount of work people choose to do. Without management being somewhat technical, it's possible to do nothing for weeks at a time, especially if you don't have good version control practices. If you don't, it's not always apparent who hasn't made a commit in over a month. I don't advocate judging work on the frequency / amount of work checked in to source control, but it should be greater than zero.
|
|
#
¿
Aug 10, 2016 16:36
|
|
|
I've only worked at tiny companies / startups and I would kill to have a decent manager / HR person / admin professional / etc. etc. etc. Companies created by people with the "Management / soft skills / anything but programming is useless!" attitude who wonder why they have high turnover and bad work relationships. I would never want a role like that for myself, but they're insanely valuable in skilled hands.
|
|
#
¿
Aug 23, 2016 22:10
|
|
|
I enjoy front end, I like interactivity and design, so it's more interesting to me than figuring out the most optimal way to join two tables. That said, the front end world is a clusterfuck right now of competing Javascript frameworks, most of which have only been "stable" for a couple years. The only way I've ever been able to wrap my mind around them is to pick a project and build a front end for it in your framework of choice. There are a lot of public APIs out there you can use so you don't even have to deal with a db if you don't want to. Building a project from scratch will show you all the conventions that framework uses for data binding, routing, and templating, and from there it's all just Javascript (unless it's ES6, or Babel, or Typescript, or, or, or...)
|
|
#
¿
Sep 13, 2016 18:22
|
|
|
Noam Chomsky posted:As a 39-yo please share your strategies for staying on top of all of front-end and the other kinds of development you do AND also leading any kind of normal human life. This is an actual serious question. I'm not who you were responding to but I wanted to clarify that when I say 'pick up a new framework' I hardly mean mastering it. This seems to be how it goes: - Hear I'm going to be switched to a project next month using (Angular / React / Ember / Backbone / Vue / etc) because former manager advocated that it was the BEST JS FRAMEWORK! Or, get invited to work on a toy project with a friend who is in the same situation. - Grab a sample of the O'Reilly book for that framework on my Kindle to see if it's readable, read the sample, maybe download the whole thing if it's <$30 and not awful to read - Dick around online long enough to figure out what the particular weirdness of this framework is - Try to create some grocery list or to do list app using the official documentation Basically, a few evenings or weekends, enough to know what I'm getting into. I don't think this is particularly overwhelming, unless you are so burnt out by your day job that you have no energy for messing around after hours. In my experience, the people I know end up doing more of this sorts of stuff when they hate their current projects, 'cause at least this way they are in control of something.
|
|
#
¿
Sep 13, 2016 21:52
|
|
|
Necc0 posted:Apparently the consultants I'll be leading are sort of rough in the people-skills category so my primary role will just be keeping them in line. - Pay attention in meetings with your stakeholders for deadlines, requirements, and priorities. Theoretically, you are not supposed to have any deadlines, but stakeholders almost always have expectations, and you need to be able to identify them and prioritize them accordingly. Likewise, stakeholders have stated requirements and priorities but there are often unspoken ones - it's your job to draw those out into the open and make sure they are correctly scoped and assigned. These often include behind-the-scenes type tasks. - Make sure your stories are complete before the sprint starts. 'Complete' means that any dev can pick up a story and understand any the reason for the story, the prerequisites, and the scope of changes needed. Arrange these in order of priority, and tell your devs how many of them you expect to have done. It should never be 100%, but it should be ~75% so that the sprint doesn't seem ridiculously long, but that there are some backlog items in case all the requirements get finished. - Do a postmortem each sprint of which goals were met and which goals were left behind and adjust your expectations accordingly. If your team is not accomplishing as many as you set out to, you need to reduce scope until you meet your goals.
|
|
#
¿
Nov 2, 2016 17:23
|
|
|
Destroyenator posted:A lot of this is really the responsibility of the Product Owner/Product Manager, the scrum master definitely shouldn't be setting priorities. But you should be there making sure it happens and helping them if they haven't worked like that before. Yes, exactly. I have been in far too many product meetings where the Product Owner(s)/Manager(s) had multiple competing priorities, and without dragging that into the open and making them argue amongst themselves about it, it became the fault of the team when these various features were "late" or "not prioritized correctly". Paying attention to a Jira board is one thing, but you should also be actively listening to what they talk about needing the most, what comes up a lot, and what seems to inspire heated debate. Point it out, and ask where that thing fits on the priority list. Make sure everyone knows and agrees about what your team is going to do this sprint.
|
|
#
¿
Nov 3, 2016 13:33
|
|
|
When I'm interviewing a company, I like to ask a lot of general questions and then watch how they answer vs. listening to the words they say. I have straight up asked "Do you like working here?" to devs in interviews - they will always tell you "Yes! it's great!" but watching how long they pause, who they look at before they answer, whether or not it sounds like they believe it - so useful. I also like to ask if people like to socialize outside of work together - it's a sign that everyone is at least polite to each other (this can also mean it's clique-y and passive aggressive, but that's harder to suss out). Also, observe the office. Do people look happy, or run down? Do people's desks show signs of stress and late hours, like trashbins full of energy drinks? There's also positive signs like people taking breaks, bulletin boards with activities and non-work news, signs of "life outside work".
|
|
#
¿
Dec 27, 2016 21:07
|
|
|
Vulture Culture posted:Counterpoint: my desk is constantly covered in soda cans and coffee cups because the company I work for has very good work-life balance, which is why I choose to work there while raising a toddler and a newborn that keep me awake all the time. I'm constantly run down -- this is what having kids is like -- but also very happy at my job. Oh totally, that's why it's important to look for trends vs individuals. I also didn't mean desks needed to be absolutely clean or anything like that. If all the surfaces are covered with dumb kinetic toys and Soylent I know I'm in the office of a of Hacker News-reading startup that will want my life to revolve around them. If there's a kegerator and nerf guns, it's going to be a post-college brogramming situation. If it's a cubicle farm with nothing but the fire code on the wall, I know that people don't really ever settle in there. Obviously I'm making a lot of quick judgements, but getting the read on a place will let you know which questions to ask to get actual information.
|
|
#
¿
Dec 28, 2016 16:42
|
|
|
My favorite part was the part where he admitted that his "studying" mainly consisted of watching youtube videos and updating his github repo of study topics. He admits in one place he "wishes he had started coding exercises earlier".
|
|
#
¿
Jan 12, 2017 17:33
|
|
|
VOTE YES ON 69 posted:"The position was substantially different than originally presented" "It was not a good fit" The way I've heard this presented is that everyone gets 1-2 of these "get out of jail free" cards in their career. If you leave after a month, after your next job you don't even have to bother listing this one on your resume. A gap of a month isn't really that much.
|
|
#
¿
Feb 28, 2017 21:08
|
|
|
Vulture Culture posted:honestly, this, phrased exactly this way This was presented as a rule of thumb for any kind of career, not just tech - it seems like the tech field regards "job hoppers" differently in general. I've heard of some hiring managers in tech looking at people staying in a position longer than 5 years as a negative, thinking they haven't kept up with modern tech, and some who even recommend that new devs always switch jobs after 3 years in order to build their resume, even if they're happy where they are. Still, I would personally be wary of someone with the majority of their jobs being very short stints without a compelling explanation, and I don't think that's an unpopular opinion.
|
|
#
¿
Mar 1, 2017 17:24
|
|
|
I've worked on a team of contractors hired to supplement another company's team of Indian contractors and it was pretty bad. I think it would be different if the Indian team was in-house rather than contractors, so that would be a good question to ask. Problems we had: - Time difference meant that ANY feedback took at least 24 hours to get a response. This meant that 3 rounds of emails would take a week, which lead to meetings either very early in the morning or very late at night in order to have a useful conversation. This has been the case with every overseas team I've ever worked with and it's always been frustrating. - If it wasn't in the contract, it didn't exist. The hiring company specced out everything from a sales perspective, asking for certain features. These had to be VERY VERY specific, or when given feedback, the overseas team would argue that it wasn't contracted and therefore they weren't responsible for it (I actually kind of admire this, as the hiring company was known for being vague). However, there was never any spec about code conventions, style, or documentation. A lot of the work from our team was cleaning up and organizing "feature-complete" code that was nightmare spaghetti code. Also, this was supposed to be an Agile product, which completely clashed with this arrangement. - On one project, where we had no access to the backend, we were only allowed to talk with the project manager of their team rather than the actual devs, which meant that everything technical had to be taken with a giant grain of salt. Many times we were told that API features were complete only to start building a frontend and discover that the feature was barebones and lacking many of the endpoints or database fields that would be required to have a functional feature. Combined with the "spec first" approach, this meant that we would have to find our project manager to draft up a new spec request to send to their project manager. So, in short, timezones make communication hard, and if it's hard then everything is hard.
|
|
#
¿
Mar 1, 2017 18:54
|
|
|
TooMuchAbstraction posted:If the startup is stable and growing, then you're not getting in on the ground floor. There's also the potential for the company, as a whole, to change very rapidly. A company can go from great to sucky in a matter of months, or even faster. All it takes is a couple experienced devs leaving and taking all the institutional knowledge with them, or a funder dropping out, and suddenly your dream startup is now having to do insane things just to stay afloat.
|
|
#
¿
Mar 21, 2017 16:24
|
|
Seriously though, startups can be very hit-or-miss; they can be great or they can really, really suck, and there's not a lot of in-between. The small employee base means that you can make a much bigger impact on the company, but they also tend to have less-experienced leadership, and interpersonal issues get magnified when there's no bureaucracy in place.
|
AskYourself posted:Yup technical debt is a tool. Can be traded for opportunity cost and time to market not exclusively. I will say that, similar to actual debt, this situation is incredibly rare and usually technical debt is being accrued because people are bad at planning ahead.
|
|
#
¿
Mar 27, 2017 20:55
|
|
|
Sinten posted:Career advice/politics advice needed. (warning: ranty and long) You've committed the sin of competence, and are being punished accordingly. This sounded remarkably like my first job, burning out talented employees and refusing to manage nonperformers. The plus side is that if they haven't fired the nonresponsive guy, you can probably coast safely and job search. Sucks to deal with constant passive aggressive comments but it seems like that's the most they're willing to confront people. Since pushing back gets you approximately nowhere, I wouldn't feel guilty about moving on in the same position. You might want to try to pick nonresponsive's brain and see if he's experienced similar - I could see burnout doing that to a person.
|
|
#
¿
Apr 15, 2017 01:23
|
|
|
dantheman650 posted:Any good D3 tutorial recommendations? Going to need it for a new position I just started. The D3 maintainer has set up example scripts for just about every possible type of graph at https://bl.ocks.org/. I fully recommend copying one that looks like your use case and then modifying it, every time. It's a very feature rich library, and unless your entire job was to create interactive graphs, it's going to be faster/easier than starting from scratch. If it is going to be your entire job, I would still recommend copying an example chart and modifying it, because it will give you more insight into what everything does than a tutorial. - Make sure you know what version you're using and what the example is using. There was a massive overhaul between 3 and 4 that caused complete incompatibilities. - If you are using it infrequently, comment like crazy. I'm not a big code commenter, but I always leave a trail of breadcrumbs on my D3 charts so that when I inevitably get feedback to change the colors or whatever I can find exactly what I need. At first I didn't think I'd needed them, since I wrote the dang chart, but even days later it was difficult to tell where to put things.
|
|
#
¿
Apr 20, 2017 03:35
|
|
|
Steve French posted:I haven't fully decided whether a policies that disallow (or strongly discourage) laptop/cellphone use during meetings is actually addressing a root problem, rather than addressing a symptom of a problem and making the actual problem worse (e.g. symptom being people using devices in an attempt to salvage some productivity in poorly run / too large meetings). I'm leaning towards the latter. I've only seen a "laptops closed" policy work out in one situation. We hired a new PM because our current not-really-a-PM got too busy with his actual job to continue doing it. Not-really was known for his long, agenda-less meetings and everyone would work throughout because otherwise you would spend half a day listening to Not-really and whoever hash out incredibly small implementation details of whatever. New PM threw an absolute fit at first about not bringing our laptops, but also had meeting agendas, shushed people who were getting off topic, and kept every meeting to a tight 30 mins. It was great. Within a month we had actual meetings and nobody really thought about bringing their laptops.
|
|
#
¿
May 4, 2017 13:53
|
|
|
actionfiasco posted:I've already started sending my resume out to other places, but I'm wondering what the best way to approach discussing this place during interviews is, especially given the short amount of time I've been working here. Is it good enough to say it just wasn't a mutual fit? Should I go into any detail on any of this if asked about why I think that? Badmouthing former jobs is a red flag for employers because they have no way to know if it's true or if you're just an rear end in a top hat. In this instance, I would use your "mutual fit" line and if pressed, follow up with something like "I didn't see any opportunity for growth at Acme, Inc" and then you can talk about how you're so excited for New Company because they are using technologies X and Y or something. The main idea is to keep anything negative short, objective, and vague. If the interviewer is smart, they can read between the lines.
|
|
#
¿
May 22, 2017 17:09
|
|
|
Honest Thief posted:I think I'm coming to the realization that I'm on the wrong field, I keep failing take home assignments for better development roles on the basis of poor documenting and/or confusing code. I admit most of my time working has been with hackey teams and a "get it done" mentality so I guess I'm just not cut out for these roles. I've been actively trying to improve those flaws but it's just never good enough. How many have you failed? I recently was involved in evaluating take home assignments for one of our coding positions. I was surprised at the code people handed in, and eventually chose the "best" based on the following criteria: 1. It ran (we eliminated almost a third for this) 2. It did something (no one submitted code that met the full spec of our tic-tac-toe game, but the best ones handled the main game logic) 3. There wasn't a bunch of commented-out code or leftover files from prior attempts at a solution (even most of the "good" solutions included this) It really seemed like most people started without any kind of plan and then fell headfirst into some complicated edge case and got stuck. I would start by outlining a quick plan and coding up the most straightforward, static version of the problem as possible. Then do whatever you think the interviewer is looking for, and finally save a portion of your allotted time to clean up and try running your program in whatever format the interviewer would. Did you get any feedback about your assignments?
|
|
#
¿
Jul 4, 2017 22:48
|
|
|
Destroyenator posted:The logic problems in that code sample could've been caught with some tests. For any code challenge stuff if the problem lends itself to testing then you should definitely write them and include them as part of your submission. A good README file explaining your assumptions and any tradeoffs as well as how to run it is also going to make reviewers much happier. Yeah, keeping in mind that this is code that will be primarily read first and run second is also important with these kinds of take-home problems. A README is always a good idea. You should also be paying more attention to how you're naming args, functions, and variables, and commenting anything that could be misunderstood. Having variables named "ret" is not great. Definitely get a friend to proof next time you do one of these. Having another set of eyes on your code will show you where your code is confusing even if everything is correct.
|
|
#
¿
Jul 5, 2017 22:50
|
|
|
Mniot posted:OK, so all the review comments on better code are good, but trying to think of what would trigger a rejection based on this code... I don't see it. I guess I could imagine a couple of the problems being annoying enough that they'd sum them up and reject. Or if you took a week on this, then that's disappointing but I'm assuming you did it in about an hour. It seems to run correctly and I can follow the code without shaking my head the whole time so I'd call it good. It really all comes down to the quality of the other candidates' code. If there were a lot of strong coders, then nitpicky stuff gets more weight. If there are a lot of candidates, you're going to screen as many out as quickly as you can so you can focus on the strongest. In those scenarios, your genius handling of some edge case won't matter if your code appears a little sketchy on first review.
|
|
#
¿
Jul 6, 2017 02:06
|
|
|
If job candidates can find and hire a dev to do their homework assignments for them in the time allotted, hire them as your new hiring manager. Two birds, one stone.
|
|
#
¿
Jul 16, 2017 20:11
|
|
|
Your manager sucks and isn't going to change. He's actively hindering you as well as blaming you for being hindered. This isn't a situation where understanding office politics will help. You need to find a new job, ASAP. It's only a matter of time before you get blamed for something big. In the meantime, try not to rock the boat too much and work on your manager's priorities, even if they are terrible and regressive. You could try going to his superiors (in the way mentioned before), but if the manager is well-liked, it could be that the whole company is run in this stupid way, which further emphasizes that you need to get. out.
|
|
#
¿
Oct 9, 2017 12:25
|
|
|
Good Will Hrunting posted:I find that even though the pay may be worse, most startups at least move faster on things. The year I spent at a financial company (or 10 months actually), they were impressed that I was able to set my environment up and trigger a dummy build in 4 days (which, lol, support desk is the only reason it wasn't done in an hour). This is 100% the reason I don't think I could ever work in enterprise software dev. At my last contracting position, to get keycard approval to get into the building took almost a week. Getting on the project's JIRA, same. Getting a company email address, same. Getting invited to project planning meetings with my project manager, same. I think it was probably two months before I was contributing any kind of value whatsoever. Compared with my first startup job where the CTO handed me a laptop and stuck me in the project manager's office until I had all that stuff, and then took me to lunch. Had my first code contribution that afternoon (fixing a minor typo on the project README, sure, but still). I just can't with bureaucracy.
|
|
#
¿
Oct 11, 2017 15:48
|
|
|
Munkeymon posted:I'm not sure where you work that doesn't bog all of that down in multiple approval levels of people who don't understand what you want other than the spend looking bad on their fiscal year-end reports because that's what I'm used to hearing about from big non-tech companies. Yeah, this right here. Many of the hurdles I encountered were budgetary: we can't add another user to our enterprise Jira without incurring fees, so that needs budgetary approval. Which means you need manager sign-off to approach the budget office, which means you need to find your personnel manager, who is different from the project manager who you see every day. Then you have to convince them that you need access to Jira and that you can't just "make do", because they have no skin in the project but do get dinged if their budget numbers go up. Etc, etc, obviously that place was a shithole, but it soured me on companies that large.
|
|
#
¿
Oct 11, 2017 18:23
|
|
|
Love Stole the Day posted:Since the Unreal Engine had recently come out as 'free' to use a la Unity I decided to specialize in that. Book after book. Every tutorial I could find. Game jam after game jam. Nowadays I'm usually the most experienced guy on my team in game jams and I'm helping new people all of the time improve with it. Still, though... it's a black hole. What are you doing to network in these companies you're applying to? Talking to guys from big successful companies is good, but I don't see anything about talking to people in the companies you're applying to. Game jams are great if there are local game companies, and if you're in any kind of city, there should be some webdev meetups. It's easier to take a chance on a guy you know than a stranger if their resume is lacking. And it sounds like yours is, specifically relevant work experience. If you're applying to companies you'd have to move for / work remotely for...good luck. They're going to see the lack of experience and probably skip talking to you unless they have no other candidates. At best, you might be offered an internship.
|
|
#
¿
Nov 13, 2017 03:40
|
|
|
Good Will Hrunting posted:Speaking of which, have you folks ever worked somewhere with 0 "scrum" or "scrum like" practices? Like, we just have a giant board of tickets. We do no planning, grooming, discussion or anything and frequently make our own tickets. There are no sprints or points assigned because my boss things it's a "waste" but myself and peers think it's to reduce transparency. Our new team lead is all for doing a bi-weekly retro and planning, which I like. Fair warning: this is something I feel very strongly about. A lot of tech people think of any non-code work activities as "wasteful". However, unless your team can fit into a small room, you need to have some codification to your communication or you end up with problems. The whole "left hand doesn't know what the right hand is doing" problem. If you are making your own tickets, how do you know that the ticket you're writing doesn't already exist on the board? How do you know that you and another team member haven't already implemented the same code in parallel, or written code that stomps all over a solution from a week prior? Grooming is super important to keep the board from piling up with useless tickets - is a major bug being ignored over and over again because it's lacking steps to reproduce? Are some problems no longer problems because they were solved another way? In my experience, the best way to increase the productivity of a team is to remove obstacles from their work. If each dev has to check each ticket against all the other ones and current codebase, that's wasting a ton of time. A team lead who can remove a greater-than-zero amount of useless tickets has prevented the entire team from having to do that individually.
|
|
#
¿
Nov 15, 2017 02:28
|
|
|
Good Will Hrunting posted:My team is stuck in an endless cycle of: get assigned 'task' from VP of Engi -> it has no spec so we try to come up with reqs and acceptance criteria and make our own Jira -> try to get spec details/reqs from product -> product ignores us or gives vague specs -> ??? -> try to build something -> say its "done" -> product says "we actually needed to do this" -> revisit. After you try to come up with your own specs, are you returning to product and asking "This is what we're going to do, is this what you meant"? I find that's much more likely to produce a response of "No, we actually need X with options for Y and Z". A lot of product owners think a feature is "totally obvious" until presented with an equally obvious-but-wrong set of specs. I am not a fan of pixel-perfect mockups / fakeups (front-end functionality w/out anything backing it up) most of the time, as they're too time consuming for most things, but they are usually less time consuming than actually building the thing and then having it be rejected over and over again. It might be helpful to start sending them that sort of thing - it's helped when I've had product owners who were bad at communicating.
|
|
#
¿
Nov 15, 2017 17:08
|
|
|
Good Will Hrunting posted:So bring it up to HR when I'm prompted for it? It's not like it would be at all surprising to expose him as toxic, I just don't want to lose my job (just yet). If your HR is any good, mentioning that you fear retaliation from a superior should raise all kinds of klaxxons and probably prompt an investigation. However, if they are bad / toothless / tend to drag their feet about this kind of thing, it could make your relationship even worse. Do you know if they suck or not?
|
|
#
¿
Nov 20, 2017 20:21
|
|
|
Good Will Hrunting posted:...she's had chats with me about how HR knows my boss is toxic and tells me if I ever feel uncomfortable to reach out to let her know and she'd provide the bridge for me. This was all prompted by something unrelated to my team - I didn't go to her, she reached out to me. Also someone quit my team and another request ed a transfer (successfully) because they cited not being able to work with my boss. Honestly from this it sounds like they are trying to build a case against your toxic boss and need corroboration. They've already lost one team member to this person, it is bad for the company to lose good talent due to one middle manager. This seems like a best-case scenario for you to be honest and benefit from that honesty.
|
|
#
¿
Nov 20, 2017 22:01
|
|
|
|
| # ¿ Apr 26, 2024 05:56 |
|
|
I have never seen a "refactor" ticket get successfully finished, they always get pushed further & further away until presumably the heat death of the universe. What I have seen succeed has been adding refactor line items into existing tickets, for example, in the Corn Dog feature, you must* refactor the Hot Dog model before Corn Dogs can be implemented. That said, I think it's valuable to try to take a campsite approach to any new work and clean up any files you touch. Some argue that this makes code review difficult, but that's a lesser evil compared with "never refactoring". *for a given value of must
|
|
#
¿
Dec 5, 2017 18:47
|
|