|
Sinten posted:Was it coincidence or did something change, like new management? A big giant 1 year estimated project was demanded to be finished within 6 months, even after they scoffed at the initial estimate and went to an external company for their estimate which was even longer. They brought in an external contracting company that savaged much of the code base and were told to lax their code review standards to allow work to be completed faster. Many offshore resources were brought in and the remaining few just lead offshore teams now. The CTO that made all these promises was also fired for being a dickhole, unrelated to his inability to perform his job well.
|
#
?
Jun 14, 2019 23:55
|
|
|
|
| # ? Apr 16, 2024 14:40 |
|
|
dantheman650 posted:Starting a new position on Monday. It’s my second real software job. Advice for the first few weeks? Don't write bugs.
|
|
#
?
Jun 15, 2019 00:04
|
|
|
Understand the team / company culture, learn the codebase, try to spend more time listening than commenting or suggesting.
|
|
#
?
Jun 15, 2019 00:16
|
|
|
dantheman650 posted:Starting a new position on Monday. It’s my second real software job. Advice for the first few weeks? You may feel like a total idiot for a month or two as you learn your new shop’s folk wisdom. This doesn’t mean you are one.
|
|
#
?
Jun 15, 2019 00:23
|
|
|
dantheman650 posted:Starting a new position on Monday. It’s my second real software job. Advice for the first few weeks? Can you juggle? Ride a unicycle? Sing? All three at once?
|
|
#
?
Jun 15, 2019 00:44
|
|
|
dantheman650 posted:Starting a new position on Monday. It’s my second real software job. Advice for the first few weeks? This is the best possible time to ask fundamental questions. Where are the tests? Why was this system designed this way? Who on the team is an expert on what, and what is our bus factor? What is the style guide? How do we plan what to work on? Don't start pushing for changes to the current system right out the gate. You don't want to be perceived as the cocky newbie who isn't interested in learning how things work around here. However, you can start dialogs about why the system is the way it is (since you are trying to learn how the system works), and you can learn how much thinking the team has done about different possible approaches. In other words, instead of saying "We should do X", say "Have we previously talked about doing X? What was the conclusion at that time?"
|
|
#
?
Jun 15, 2019 01:17
|
|
|
necrobobsledder posted:Understand the team / company culture, learn the codebase, try to spend more time listening than commenting or suggesting. TooMuchAbstraction posted:Don't start pushing for changes to the current system right out the gate. psh, this is no way to be. how!! it up and suggest a ground-up rewrite for every component that's even mentioned around you on day 1
|
|
#
?
Jun 15, 2019 01:51
|
|
|
dantheman650 posted:Starting a new position on Monday. It’s my second real software job. Advice for the first few weeks? One really good contribution a new developer can make at a company is updating their READMEs / documentation / etc. Try to follow (any) documentation they have to get your dev environment set up, and update it as necessary.
|
|
#
?
Jun 15, 2019 03:49
|
|
|
vonnegutt posted:One really good contribution a new developer can make at a company is updating their READMEs / documentation / etc. Try to follow (any) documentation they have to get your dev environment set up, and update it as necessary. This, so much this. The first time perspective is almost impossible (for me, anyway) to fully empathize with. Don’t just "figure it out" and move along, fix the doc and you’ll be my hero.
|
|
#
?
Jun 15, 2019 04:13
|
|
|
I forgot where I'm posting. Suggest a rewrite of the codebase in Elixir and start with the most critical core component so that its performance improvements impact as many parts at once. Containerize your database in production to improve availability. Migrate your GUI facing pieces to Electron while you're at it. Make sure to start a new project and name it after an anime character that best represents its spirit. Never include anyone else because any badness in existing code was by definition created by that team and it's important to start from a baseline of excellence free of corruption and legacy behavior.
|
|
#
?
Jun 15, 2019 06:26
|
|
|
JawnV6 posted:psh, this is no way to be. how!! it up and suggest a ground-up rewrite for every component that's even mentioned around you on day 1 Is there a name for this behavior? It's like the polar opposite of imposter syndrome: in the face of many systems that you don't understand how to work with, necrobobsledder posted:I forgot where I'm posting. ^^^ this ^^^
|
|
#
?
Jun 15, 2019 16:50
|
|
|
prisoner of waffles posted:Is there a name for this behavior? It's like the polar opposite of imposter syndrome: in the face of many systems that you don't understand how to work with, The Dunning-Kreuger effect. A.k.a. your lack of knowledge leads you to be supremely confident in your abilities instead of extremely uncertain.
|
|
#
?
Jun 15, 2019 17:07
|
|
|
Now that I'm no longer phone posting I won't poo poo post. I'm starting a new role on Monday as well taking on two back end teams that haven't had close management for a long time. My approach that can also work for an IC is to break up the job into three broad categories, People, Process, Technology. For an IC that first week or two can be: People: Meet the team, talk with your lead, get the 1:1s scheduled and have the initial one. Make sure that the expectations for the role are clearly defined to you as well as how/when follow-ups will happen. Process: How do you get the code on your machine? Build and run it in the dev environment. What's the pre-commit rituals? Understand how you get code from your machine to production. How are things tasked? What's the rituals around Agile/Scrum/anything else? Technology: Get an overview of the architecture. How's the documentation there? Can you improve it? Is there a tech road map for what's going on in the future? Spend time reading wikis/confluence to learn what's there. Make your first commit. Others can probably add/subtract from the list but something like that I think is a good first 5 days to go through. As a manager my plan is basically that but writ large and over 2 weeks. IE: Make sure I have had initial 1:1s with everyone. See if there are common complaints and come up with ways to make a change to address them. Talk through the POs and VPs with what the 9 month road map looks like etc... By the end of the 2nd week I should have a meeting with a team wide introduction as well as any plans going forth.
|
|
#
?
Jun 15, 2019 17:22
|
|
|
TooMuchAbstraction posted:The Dunning-Kreuger effect. A.k.a. your lack of knowledge leads you to be supremely confident in your abilities instead of extremely uncertain. That's not the Dunning-Krueger effect.
|
|
#
?
Jun 15, 2019 17:23
|
|
|
Oh yeah, I forgot make sure you know what is expected of you... and proceed to do absolutely none of that. "Concerned" is code for "I don't know what you're doing" and is a sign to keep things up because they don't know greatness since they haven't witnessed it by then. Because if they were right about setting expectations and goals for people they wouldn't have needed to hire you, right? For fucks sake don't do any of this, this is SA. Each and every one of these things I've mentioned in the past couple posts have been done or uttered confidently by people I worked with briefly. Briefly because all were fired within 1 month after my arrival even from normally cushy executive positions. Or do it all with no exception and post to the forums with daily updates prisoner of waffles posted:Is there a name for this behavior? It's like the polar opposite of imposter syndrome: in the face of many systems that you don't understand how to work with,
|
|
#
?
Jun 15, 2019 18:15
|
|
|
Gildiss posted:A big giant 1 year estimated project was demanded to be finished within 6 months, even after they scoffed at the initial estimate and went to an external company for their estimate which was even longer. Especially the part I bolded makes me scream out loud. Hughlander posted:Find the biggest guy you can and....
|
|
#
?
Jun 15, 2019 19:24
|
|
|
https://medium.com/feature-creep/the-software-engineer-s-guide-to-asserting-office-dominance-ddea7b598df7
|
|
#
?
Jun 15, 2019 22:28
|
|
|
I'm shocked and saddened that it took that many posts for that article to appear ... and that I didn't post it.
|
|
#
?
Jun 17, 2019 14:49
|
|
|
I'm working on a side project with another that's likely to take multiple months, so we're looking for some way of storing plans, notes, institutional knowledge, etc. There are about 3 million different options, anyone have recommendations for that sort of thing or should I just keep writing Google Docs
|
|
#
?
Jun 18, 2019 18:13
|
|
|
muon posted:I'm working on a side project with another that's likely to take multiple months, so we're looking for some way of storing plans, notes, institutional knowledge, etc. There are about 3 million different options, anyone have recommendations for that sort of thing or should I just keep writing Google Docs Is there any reason github wikis wouldn't work for you? If not google docs are totally fine.
|
|
#
?
Jun 18, 2019 19:51
|
|
|
I've personally found markdown files that you commit into sourcecode as a great way to codify non-code related things. It helps that it's already a super familiar workflow for software engineers.
|
|
#
?
Jun 18, 2019 20:13
|
|
|
...and if you name them README.md then GitHub will show it automatically when you look in that folder.
|
|
#
?
Jun 18, 2019 20:18
|
|
|
TheCog posted:Is there any reason github wikis wouldn't work for you? If not google docs are totally fine. Haven't looked into it, I'll check that out, thanks! Doh004 posted:I've personally found markdown files that you commit into sourcecode as a great way to codify non-code related things. It helps that it's already a super familiar workflow for software engineers. Makes sense. My personal site is all markdown files generating a static site via Hakyll, it's a pleasing user experience.
|
|
#
?
Jun 18, 2019 22:51
|
|
|
muon posted:I'm working on a side project with another that's likely to take multiple months, so we're looking for some way of storing plans, notes, institutional knowledge, etc. There are about 3 million different options, anyone have recommendations for that sort of thing or should I just keep writing Google Docs If you like emacs, this is what org-mode is for.
|
|
#
?
Jun 19, 2019 00:49
|
|
|
I might be a weirdo for liking Quip. No, not the toothbrush https://quip.com/
|
|
#
?
Jun 19, 2019 00:59
|
|
|
I had to use Quip a few years ago at FB, because they refuse to use any Google products. It was awful. As I recall, Quip started out as an FB-internal tool, then the devs left and founded their own company, rebuilt the product... and sold it back to FB. While of course they built it again from scratch, it just so happened to look exactly like the original internal product, even down to the CSS styles and colors... *cough*
|
|
#
?
Jun 19, 2019 02:30
|
|
|
Notion is pretty great
|
|
#
?
Jun 19, 2019 03:46
|
|
|
I’m in my first programming job. We recently started to do sprints, since we are starting to do production code instead of proof of concept code. For the past couple of one on one meetings with my manager, I have been asked for feedback on our sprint meetings. I don’t really contribute to the meetings except for my sprint demo. I am not sure how or what I would give feedback about. I don’t know anything about stuff I should prefer or dislike in sprint meetings. I don’t know anything about project management. How do I form opinions on project management?
|
|
#
?
Jun 19, 2019 05:18
|
|
|
Faith For Two posted:I’m in my first programming job. We recently started to do sprints, since we are starting to do production code instead of proof of concept code. "I am not experienced enough in this sprint thing to comment on it." But actually I think your manager wants to hear you don't like it so he can kill it and go back to a process he understands.
|
|
#
?
Jun 19, 2019 05:54
|
|
|
Giving the benefit of the doubt, the manager is doing a retrospective. If they just started the process, they probably read about that somewhere and are just following along.
|
|
#
?
Jun 19, 2019 07:07
|
|
|
Faith For Two posted:I’m in my first programming job. We recently started to do sprints, since we are starting to do production code instead of proof of concept code. You give the same feedback you’d give about any other meeting. “It was a boring waste of time.” “It was a good way to keep abreast of what the rest of the team is up to.” “The principle is good, but we kept getting side-tracked, so tighter moderation would be good.” Meetings should serve their attendees’ interests, and your boss is trying to figure out if this is the case for you.
|
|
#
?
Jun 19, 2019 13:31
|
|
|
Are these sprint planning meetings, where you decide what to work on? Are they scrums, where everyone quickly says what they're doing and what's getting in their way? Are they the retrospectives, where you look at how the last sprint went so you can tweak the next one? Planning meetings are mostly the domain of the team leads and project managers; I wouldn't normally expect the rank and file to be attending those. With scrums, IMO the best way to handle them is virtually: have a team chat or email or whatever where every day (or whatever your scrum interval is) people speak up about what they're doing. It's less intrusive than a fifteen-minute meeting. And really the point of the scrum is to make sure nobody's doing duplicate work or unknowingly blocking someone else. You don't need in-person realtime discussions to achieve that.
|
|
#
?
Jun 19, 2019 15:46
|
|
|
necrobobsledder posted:I might be a weirdo for liking Quip. Quip has customers outside of Salesforce!?
|
|
#
?
Jun 19, 2019 17:45
|
|
|
TooMuchAbstraction posted:Are these sprint planning meetings, where you decide what to work on?
|
|
#
?
Jun 19, 2019 18:34
|
|
|
Vulture Culture posted:This might be both obvious and beside the point, but sprint planning meetings (in a Scrum sense) are generally not for deciding what to work on. This is product team work and it's typically a big waste of everyone's time to make engineering teams sit through this Yeah, I only listed that one because in my experience it's not at all uncommon to invite people to meetings they have no business being in.
|
|
#
?
Jun 19, 2019 18:54
|
|
|
Rocko Bonaparte posted:Haha I don't know what to think about this. Was that boss self-aware and considered a two-week notice an improvement or something? Sorry I haven't kept up on this thread. The answer to this question is no, no he's not self-aware, dude is far too rich and comfortable to be self-aware.
|
|
#
?
Jun 19, 2019 20:35
|
|
|
Vulture Culture posted:This might be both obvious and beside the point, but sprint planning meetings (in a Scrum sense) are generally not for deciding what to work on. This is product team work and it's typically a big waste of everyone's time to make engineering teams sit through this We use sprint planning with the entire team there so we can influence what we work on and commit to in a sprint. As soon as others start telling me what needs to happen in what timeframe, I would check out and start looking.
|
|
#
?
Jun 20, 2019 19:06
|
|
|
Might be in a new job soon. Will have to do UI stuff. Did MFC stuff back in the day for C/C++. If they ask for modern stuff what do I do? Is it worth getting round to C# and do WPF stuff or some C++ ui library?. This would be for terminals/screens not the web. Not been told exactly what it will be on but thinking touchscreens or PC and mouse affairs. Want super reliable ideally but then don't we all, but will be a bit more mission critical in terms of what it is used for.
|
|
#
?
Jun 20, 2019 20:56
|
|
|
FelchTragedy posted:Might be in a new job soon. Will have to do UI stuff. Did MFC stuff back in the day for C/C++. If they ask for modern stuff what do I do? Is it worth getting round to C# and do WPF stuff or some C++ ui library?. This would be for terminals/screens not the web. Not been told exactly what it will be on but thinking touchscreens or PC and mouse affairs. Want super reliable ideally but then don't we all, but will be a bit more mission critical in terms of what it is used for. from what I can tell, the only UI platform that exists anymore is Electron. mostly joking
|
|
#
?
Jun 20, 2019 21:03
|
|
|
|
| # ? Apr 16, 2024 14:40 |
|
|
Careful Drums posted:mostly joking no you're not
|
|
#
?
Jun 20, 2019 21:14
|
|
