|
Any good tools or techniques for planning out an application. I find myself spinning my wheels trying to solve one problem and getting side tracked by another that reveals itself working on the first. I'm working pretty much solo on this, no stories, no BAs, no masters. Building an online interface to View/Edit/Create nested data.
|
#
?
Nov 20, 2017 15:57
|
|
|
|
| # ? May 20, 2024 02:46 |
|
|
Officially starting my new remote job today. It's a 3-hour time difference and it's the first day, so it's a strange feeling to not really know what you're supposed to be doing until around noon...
|
|
#
?
Nov 20, 2017 16:21
|
|
|
Task #1: Watch Price Is Right
|
|
#
?
Nov 20, 2017 16:28
|
|
|
Pollyanna posted:Officially starting my new remote job today. It's a 3-hour time difference and it's the first day, so it's a strange feeling to not really know what you're supposed to be doing until around noon... How was your last day at the old place? Have a fun exit interview?
|
|
#
?
Nov 20, 2017 16:39
|
|
|
Task #1 for me is usually to spend several hours configuring my workstation and downloading+installing software. Got to do that twice this job because the first laptop died after ~a week or so. Revision A hardware :\
|
|
#
?
Nov 20, 2017 16:58
|
|
|
Pollyanna posted:Officially starting my new remote job today. It's a 3-hour time difference and it's the first day, so it's a strange feeling to not really know what you're supposed to be doing until around noon... Nice. Good luck. Post something to the office IM so they know you're up and working. Good opportunity to poke around the code base/online repositories to see what permissions you're missing/read up on and/or practice with some technique or language you like. Gildiss posted:Any good tools or techniques for planning out an application. I find doing the same sort of ticket creation I'd do for a large project helps me plan out solo tasks too. The biggest thing though is that it gives me a way to make a note to go back and fix something later instead of getting sidetracked into working on things that aren't actually a problem right now. Basically, break each chunk down into 1 day or less tasks and write down those tasks in some way that you can mark them off as you complete them or add more as you discover them.
|
|
#
?
Nov 20, 2017 17:12
|
|
|
LLSix posted:Nice. Good luck. Post something to the office IM so they know you're up and working. Good opportunity to poke around the code base/online repositories to see what permissions you're missing/read up on and/or practice with some technique or language you like. Also, commit something that breaks the build on your first day, so your coworkers know you're hardcore.
|
|
#
?
Nov 20, 2017 17:22
|
|
|
LLSix posted:Basically, break each chunk down into 1 day or less tasks and write down those tasks in some way that you can mark them off as you complete them or add more as you discover them. I do this with Trello. Small projects get a card, larger ones might be split into multiple cards, add task lists to each card for the specific things that need to be done. Arrange the cards in columns by priority. I use Today, Tomorrow, This Week, Next Week, and Someday
|
|
#
?
Nov 20, 2017 17:30
|
|
|
CPColin posted:Also, commit something that breaks the build on your first day, so your coworkers know you're hardcore. That's not hardcore most places I've worked :\ Force push an empty repo to head 
|
|
#
?
Nov 20, 2017 18:21
|
|
|
Munkeymon posted:That's not hardcore most places I've worked :\ Bonus points if the commit message is an ASCII art cowboy.
|
|
#
?
Nov 20, 2017 18:24
|
|
|
Drop a table in Production on your second day. After everybody is done scrambling around to restore the table from a backup, say, "Oh, I didn't know I was working on Production, because who the hell gives an employee write access to Production after two days?"
|
|
#
?
Nov 20, 2017 18:48
|
|
|
Lumpy posted:Bonus points if the commit message is an ASCII art cowboy. A link to https://www.youtube.com/watch?v=MYtjpIwamos is also acceptable. CPColin posted:Drop a table in Production on your second day. After everybody is done scrambling around to restore the table from a backup, say, "Oh, I didn't know I was working on Production, because who the hell gives an employee write access to Production after two days?" Yeah now we're talkin'
|
|
#
?
Nov 20, 2017 19:10
|
|
|
lifg posted:How was your last day at the old place? Have a fun exit interview? It was more or less covering the same stuff as a one-on-one had covered a week prior: changes in management, business practices, and executive sensibilities had left developer happiness and confidence in the shitter and ongoing layoffs/quits/people getting let go had eroded any feeling of stability and job security in the organization. Just that this time, the "what do we do now?" question had been answered - I decided to leave. Munkeymon posted:Task #1 for me is usually to spend several hours configuring my workstation and downloading+installing software. Got to do that twice this job because the first laptop died after ~a week or so. Revision A hardware :\ Yup, same - add "getting used to Thunderbolt 3" to the list, too. I've never used the newer MBPs before and I bought all my stuff completely forgetting that new MBPs don't have USB2 ports  LLSix posted:Nice. Good luck. Post something to the office IM so they know you're up and working. Good opportunity to poke around the code base/online repositories to see what permissions you're missing/read up on and/or practice with some technique or language you like. That's basically been my morning, that and filling out W-4s and direct deposit forms and poo poo. Can't wait to get access to the repos and dig into the code itself! I've already got a first task, which is to review the onboarding steps and see how we can improve it...I can already identify a few areas to fix.
|
|
#
?
Nov 20, 2017 19:20
|
|
|
Pollyanna posted:I've already got a first task, which is to review the onboarding steps and see how we can improve it...I can already identify a few areas to fix. Holy hell, I wish that were every new employee's first task everywhere!
|
|
#
?
Nov 20, 2017 19:27
|
|
|
Pollyanna posted:Yup, same - add "getting used to Thunderbolt 3" to the list, too. I've never used the newer MBPs before and I bought all my stuff completely forgetting that new MBPs don't have USB2 ports Surely as a Mac user you just expect to have to buy twenty adapters or all new hardware every time you unbox a new machine at this point, right?
|
|
#
?
Nov 20, 2017 19:36
|
|
|
Gildiss posted:Any good tools or techniques for planning out an application. Since I’m in web dev land, I normally sketch (literally) out the the screens I want. Then build something to make those work. If I’m doing pure backend work, I’ll write the API I want first.
|
|
#
?
Nov 20, 2017 20:03
|
|
|
Munkeymon posted:Surely as a Mac user you just expect to have to buy twenty adapters or all new hardware every time you unbox a new machine at this point, right?
|
|
#
?
Nov 20, 2017 22:06
|
|
|
CPColin posted:Holy hell, I wish that were every new employee's first task everywhere! Well, technically, it's a couple bugs - but critiquing onboarding is what I've actually ended up doing. That counts as being self-driven, right? 
|
|
#
?
Nov 20, 2017 22:34
|
|
|
I broke something in production my first Friday at my current job and I’m the lead ops engineer. I broke things by deploying our software with Cloudformation (that I didn’t write) and because a variable was different between prod and non-prod it proceeded to scale down almost all our instances. Almost everything is super stateful (the guys I inherited that all from didn’t want to put anything in CFN because everything is so brittle). No data was lost and monitoring showed zero blip in our services, but I’ve been writing tools to stop me (or someone like me) from doing that again. I’ve never seen a place go from stateless everything to state everywhere by design. CPColin posted:Holy hell, I wish that were every new employee's first task everywhere!
|
|
#
?
Nov 21, 2017 01:46
|
|
|
Has anyone done unit testing as a team to get it off the ground? It's really the only way I can think of to get it going amongst our developers. It's mostly something that's been ignored (from the CTO -> Pleb). I'm trying to change that. It's hard to deny a pull request from your boss because of a lack of unit test. So now we're into React, and so far, we've already taken as a team to design components together and potentially using this in sprint grooming / planning in the future. I want to expand it to testing as well. I've tried the "lead by example" in my role but it never sticks, even up the chain. Mostly I think we're so focused on getting things to work that we don't get things to work correctly. For my company, it's definitely a code now, regret later environment and I want to change that. Has anyone gone through this process and has it worked?
|
|
#
?
Nov 21, 2017 03:20
|
|
|
Best way to ensure you're writing unit tests is to write them first. Test-driven development, 's called. There's literature on the topic that you can use to get started. Then to ensure people care about it, in addition to CI, you may want to take the comparatively extreme step of setting up a pre-commit hook that runs the test suite.
|
|
#
?
Nov 21, 2017 04:47
|
|
|
Bongo Bill posted:Best way to ensure you're writing unit tests is to write them first. Test-driven development, 's called. There's literature on the topic that you can use to get started. Then to ensure people care about it, in addition to CI, you may want to take the comparatively extreme step of setting up a pre-commit hook that runs the test suite. If his boss hasn't bought into the idea, setting up a pre-commit hook requiring tests is going to end very poorly for him the next time his boss commits code. This isn't a technical problem, he needs to convince his team/boss of the value of unit tests, not try to force it on them with clever tech. There may not be an easy way to do this, people don't often make great changes until something bad happens. Best way may just to continue putting tests on his stuff, and hopefully a (minor) catastrophe illustrates the value of them.
|
|
#
?
Nov 21, 2017 04:57
|
|
|
Skandranon posted:If his boss hasn't bought into the idea, setting up a pre-commit hook requiring tests is going to end very poorly for him the next time his boss commits code. This isn't a technical problem, he needs to convince his team/boss of the value of unit tests, not try to force it on them with clever tech. There may not be an easy way to do this, people don't often make great changes until something bad happens. Best way may just to continue putting tests on his stuff, and hopefully a (minor) catastrophe illustrates the value of them. I guess I was thinking of it more from a perspective of getting people who are already convinced to develop the desired good habit.
|
|
#
?
Nov 21, 2017 05:02
|
|
|
I think the only way to accomplish that is to get promoted to a leadership role and impose it on the team you're leading. Trying to change an entire organization's habits is quixotic if you're toward the bottom of the hierarchy.
|
|
#
?
Nov 21, 2017 06:18
|
|
|
fantastic in plastic posted:I think the only way to accomplish that is to get promoted to a leadership role and impose it on the team you're leading. Trying to change an entire organization's habits is quixotic if you're toward the bottom of the hierarchy.
|
|
#
?
Nov 21, 2017 06:38
|
|
|
Yeah, the first step to changing the behavior is to get buy-in from folks. If everyone is already on board, you just need to figure out how to get everyone to bake it into their workflow. If not, you'll probably want to start gather metrics. Like, how long does it take for code in a new feature to break, how big are the breaks, how many bugs crop up, if you have to go in and change or fix things take a measure of how long that takes. Keep track of how the current process is doing (or not doing as the case is.) I think it's easier to try stuff like this on new feature development rather than maintenance/bug fixes so maybe propose a shakeup for your next new feature. Try and get the CI executor built into the PR pipeline (you can't merge code until the tests run successfully/break) so it provides a visual reminder to people to write tests when they check in code. Even better if you have a template for your PR text body that you can add a checkbox too (have you written tests for this?) You need to get people to think of writing tests as part of "code complete". Not something you do afterwards. Then, once you've wrapped the feature and have hopefully been able to convince everyone to write those unit tests. Measure how the feature does in production. Do you have less issues, does the code seem more stable? If things work out in favor of it, you might even be able to convince your boss to let the team take a day or two and write up more unit tests for old code that isn't covered. At least the happy path stuff. edit: When you're trying to add new tools/processes to a team, make sure you don't get bogged down in cost/benefit analysis. You mostly want to pick a solution that is easy and will make sure people write those tests. Then once you've been doing it for a while, take stock of what's working and what isn't and decide if your choices were good or if you need to update/move on to something else.
|
|
#
?
Nov 21, 2017 06:48
|
|
|
geeves posted:I'm trying to change that. It's hard to deny a pull request from your boss because of a lack of unit test. It shouldn't be. But tbh I've never worked in a culture where it's possible for someone to be a fellow developer and simultaneously be my "boss". If you develop software together as a team there should be a level of trust where you can discuss anything in a pull request, no matter who created it. If that isn't the case, you have bigger problems than a lack of unit tests.
|
|
#
?
Nov 21, 2017 07:57
|
|
|
Messyass posted:If you develop software together as a team there should be a level of trust where you can discuss anything in a pull request, no matter who created it. If that isn't the case, you have bigger problems than a lack of unit tests. Hallelujah.
|
|
#
?
Nov 21, 2017 10:09
|
|
|
New job has a codebase that only works locally if you use Webstorm. I miss Atom. 
|
|
#
?
Nov 21, 2017 21:40
|
|
|
fantastic in plastic posted:I think the only way to accomplish that is to get promoted to a leadership role and impose it on the team you're leading. Trying to change an entire organization's habits is quixotic if you're toward the bottom of the hierarchy. Public shame is a powerful tool
|
|
#
?
Nov 22, 2017 01:22
|
|
|
Bongo Bill posted:Best way to ensure you're writing unit tests is to write them first. Test-driven development, 's called. There's literature on the topic that you can use to get started. Then to ensure people care about it, in addition to CI, you may want to take the comparatively extreme step of setting up a pre-commit hook that runs the test suite. I don't like how draconian TDD and some of its supporters can be. I think a mix of TDD and regular unit testing work well for a lot of how we work. Today and yesterday we had two meetings to design a component with everyone in the room. The first one was discussing everything that was needed. The second was writing tests from the notes on the first one with everyone involved. Congratjorbations! In 45 minutes we had a simple Button Component with required properties designed and tested and passing. And yes, most of this was done in TDD way designing the first tests before coding the component. fantastic in plastic posted:I think the only way to accomplish that is to get promoted to a leadership role and impose it on the team you're leading. Trying to change an entire organization's habits is quixotic if you're toward the bottom of the hierarchy. You may be right. A while back I was promoted to my company's Principal Engineer (I don't manage anyone) and I've largely been able to define that role as it was created for me. It's taken some time for me to be comfortable in flexing those muscles, but I think I'm finally starting to get there - or at least being able to figure out how to work the role within the company. While I still have management (who also codes) above me, a lot of the direction is increasingly defined by me then endorsed by management. But I think my coup de grace today was getting our VP to join our meeting and have them say, "Yes, this is what we should be doing." We used to have an employee who was full-blown TDD, gerrit, etc. and I really liked working with him. But he would just wag his finger and hope that everyone fell in line (nobody did - including me). While I haven't been taking up his mantra 100%, I've taken the parts of it that I thought I could get wins from and tried to get buy-in in a gradual way.
|
|
#
?
Nov 22, 2017 03:07
|
|
|
Pollyanna posted:New job has a codebase that only works locally if you use Webstorm. I miss Atom.
|
|
#
?
Nov 22, 2017 03:41
|
|
|
geeves posted:I don't like how draconian TDD and some of its supporters can be. I think a mix of TDD and regular unit testing work well for a lot of how we work. I think TDD is rarely the best way to write software, but getting people in the habit of writing tests for everything is one of the things that it's really good for.
|
|
#
?
Nov 22, 2017 06:09
|
|
|
Pollyanna posted:New job has a codebase that only works locally if you use Webstorm. I miss Atom. Run it in a vm? Also: how is it limited to run locally only using webstorm? Keetron fucked around with this message at 11:29 on Nov 22, 2017 |
|
#
?
Nov 22, 2017 10:52
|
|
|
Pollyanna posted:New job has a codebase that only works locally if you use Webstorm. I miss Atom.
|
|
#
?
Nov 22, 2017 11:48
|
|
|
Plorkyeran posted:I think TDD is rarely the best way to write software, but getting people in the habit of writing tests for everything is one of the things that it's really good for. Just had a client meeting about a new requirement that originally came through as numerous impenetrable semi-coherent Word and Excel documents that described a hacky, unworkable technical solution (that was broken on many levels) to a business case that wasn't defined. We pushed back and asked 'what is the actual business use case' and it took their BA literally 1 minute to tell us everything we need to know. Seriously would have been a short paragraph in an email, and now we can also build a correct solution that's dead simple. Technical solutions as requirements are bad!
|
|
#
?
Nov 22, 2017 12:40
|
|
|
My Rhythmic Crotch posted:Unacceptable. Have you thought of looking for a new job? Sagacity posted:Well, you almost it through your first week. Good luck resuming the job hunt! Naw gently caress that, I’m gonna figure this out and adapt it to my own workflow. Keetron posted:Run it in a vm? There’s some configuration written with Webstorm in mind, since we need to spin up and interconnect various servers to get local dev working. I’m just not sure how to replicate that outside of Webstorm, like if I’d need to use Docker or something (unlikely since all our stuff is in one repo). I don’t understand the problem domain and technical needs well enough to call shots on it, but I can at least tell when something is cumbersome as gently caress!
|
|
#
?
Nov 22, 2017 15:16
|
|
|
Cant you just start it using webstorm and edit files in your ide of choice? You can also give jetbrain a chance, some of their stuff is really on point with making your life easier.
|
|
#
?
Nov 22, 2017 15:36
|
|
|
I’m just used to Atom I guess  yeah, I can do that. Still wondering why we should use Webstorm to get it running, tho...will dig into it.
|
|
#
?
Nov 22, 2017 15:45
|
|
|
|
| # ? May 20, 2024 02:46 |
|
|
Pollyanna posted:Naw gently caress that, I’m gonna figure this out and adapt it to my own workflow. So they're just using the built-in environment setup GUI to start stuff in the right order? That might be output as a script somewhere. Or just find the shortcut configuration that makes it work like Atom - editors are mostly fungible that way. E: https://www.jetbrains.com/help/webstorm/run-debug-configurations.html is what I was talking about
|
|
#
?
Nov 22, 2017 16:21
|
|