kat
It's pretty common to have quick unit tests so you can cycle thru TDD without having to recompile the world and start-up/reload the application. You can get a few hours of work done with TDD without ever opening the actual application. In legacy enterprise, you're rarely doing green field work. You usually spend time reading coding and planning a safe edit. When you do change a line and have to recompile the world, its common to actively read and plan your next change while waiting.
This is my current mind-changing book. Its a great framework for explaining how different types of people handle complexity, and how/why people react the ways they do. I really like how the framework is framed around 'complexity' rather than maturity. I've gained a much more constructive approach to handling disagreements rather than a 'smarter/better than thou' approach.
I don't want to tamper anyone's disgust. I would like to add that it happens in my home country and it breaks my heart.
I wanted to add a data point that forced birth control happens in Canada. Forced birth control is not something limited to the CPP handbook.
[Edit] I am against forced sterilization by anyone on to any one. I want to highlight that sterilization has happened in recent years in Canada. As the message above me points out, there is very little outcry in North America. Here is a data point where sterilization has happened in Canada and there is very little public outcry or knowledge of the situation.
Convergent patterns between grizzly bear genetics and Indigenous language groups
I've worked both in early stage startups and in companies that are established and are still using their original startup code base. I've seen some terrible design decisions coupled with quality code that survived 15 years because the company had amazing market fit. It cost the developers a lot of extra time to work around the poor design decision, but the company was profitable enough to make up for the dev cost. That's the most common situation I've seen. The best codebase I've ever worked with was beautiful because the company had long lead time on sales(avg deal took 12 months) so the developers had time to refactor as needed. This company is still alive, so I consider them a success!
The other factor in code quality + business success is team size. With a big team and poor quality code, it spirals down much faster, each new bug/feature gets harder and slower to implement. If its bad code but its always the same 2 developers, they will be consistent enough in their own styles that the code base will not degrade nearly as fast.
I'm Canadian, and went thru post secondary in Canada. This is coming from someone who did not program for fun in highschool, had no family support/introduction to IT, no extra curricular programming introduction, etc.
I went to a collage instead of university. My first year computer courses had lab sessions where our teacher helped with programming assignments. There was ~10 kids in class. Uni classes were a few hundred kids in a single class and lab sessions were ~30 kids. They had TAs (teaching assistants, graduate students with no industry experience) instead of their professors during programming lab sessions. I got the same course credit, much cheaper tuition, and a much more practical programming education. I transferred to a university to finish my degree and I was embarrassingly ahead of everyone else when it came to programming.
Whatever course you do take, look for passionate people with a teaching background and a small class size.
I've always had clean thick long blonde hair, which happens to be lice's favourite hair type. Every time there was a lice outbreak in school, I got it. Its very much a thing in Canada still.
Both ends of this spectrum can also result in physicals health issues too. Get a stomach bug and end up with post-infections IBS. On the other hand, stress from fear of germs could also cause IBS. Sadly you end up with the same result. Both approaches, when taken to the extreme, can cause equal amounts of health issues.
If you are interviewing for a new position, ask something about "how do you onboard new employees" , "do you have a mentoring program?" , "what does a developer do when they are stuck on a problem". If someone tells me I'm going to fix a bug on the first day of work, I always ask who is going to coach me through that! I watch how the interviewers interact with each other. Do they laugh with each other or is everyone in the interview silent and just listening to the boss? I also look for diversity on the team (some married, some not, some old, some young, etc) because where there is higher diversity there is more chance you'll click with someone who will be happy to support you. Explicitly state your job hunt is to find a more supportive culture that will coach you through your growth. Good luck either way!
What really helped was the PM team was very consistent as well. They knew how important consistency was and didn't argue if one team had already designed a save button, then they were cool with using the same button on the other sub team. Make sure you have full agreement with your PMs!
Lastly, unit test everything! The core team was frequently blocking the sub teams because they would make breaking changes. Now that our process and teams are a bit more mature it happens less, but working on the culture around this will help. Ensure that people see it as "helping out another team" rather than a "us vs them" situation. Having a CI system that runs tests on code before its checked into master is worth every second spent creating and maintaining it. And also checkin code asap, you'll have less integration issues. We also had QA that tested across the subTeam work.
I'm not sure what the name of this is, but it worked for us :)
Some people will tell you that they dont allow developers to refactor because its risky and there are higher business priorities, but before you listen to them, ask about the context. My team's official line is no-refactor because we can't break our API because our support contracts are 5+ years. That's true, but under the hood we are refactoring a little every day (split a giant method into a few new classes, add wrapper classes so we can add a unit test to previously untested code, etc)
Also, if you're good at the skill "good at reading bad code", your teammates at any job are going to be very grateful! There's not a lot of people are good at it and enjoy that!
Here's more about sweeteners on the FODMAP diet (RN reviewed too!) https://alittlebityummy.com/the-ultimate-guide-to-low-fodmap...
We needed to update tls and other security areas, customers would have sued us and/or left us otherwise. This was made possible by refactoring into microservices. We also did it for quicker deployments, again customers were seeing our competitors update a website with no down time, so if we didn't switch to microservices to increase our deploy time, we would have failed and lost customers. (This is a > 10 year code base for B2B enterprise software, so don't judge us too harshly on these short comings)
Quantified savings is a hard and confusing thing to track from a tech perspective, but a sales person stating how many licenses you're going to loose if you don't do x is pretty easy to track!
Lots of people have mentioned how important it is that you communicate, and equally important is, you need to find other people who communicate well and willingly! Its incredibly hard to teach yourself everything, and even if you attempt to teach yourself what you dont know, well timed feedback from another person can save you hours. Same with imposter syndrome, working with good people helps mitigate your self-doubt. Get feedback faster and spend last time thrashing (ie painfully learning) the basics.
Also, if you're living in another state getting a US drivers license might be impossible (how do you prove residency if your work visa is for a different state?) . Some states don't require residency for a drivers license, (Oregon and CA don't) but you can get a RealID on your DL if you can prove residency. RealIDs are strongly suggested because you can use them to fly in the States, instead of your Cndpassport + work visa. Again, TSA agents have the legal ability to detain anyone on a work visa, so having a RealID lowers the chance of complications.
All immigration to Canada is based on points (unless you marry a Canadian or have family sponsorship). The most surprisingly thing about the points system is it heavily favours anyone under mid-30s and it favours single people (spouses are considered "extra").
If you're an American citizen with a bachelors degree, look into a TN visa. They are "easy" because they have less requirements (no language proof, no worry about points, spouses, etc) but can be more difficult to get as it requires your employer to sponsor you.
Barbados Welcome Stamp (12 month visa)
Everyone is a junior at some point in their career and I don't think there is anything wrong with doing what your boss tells you to do!
If you wrote unit tests for your code, "Wrote Unit tests, maintaining 80% coverage which reduced QA cycles and increased code quality". or "Programmed on a product for x Industry, facilitating x% faster workflows for the customer"
My 2cents of advice are be upfront about what type of visa you will need when you start the interview process. Don't trust that the HR will know the correct visa and requirements. Do you own research about processing times for the visa, make sure you look at recent data for this!
Good luck!
Also, join Rand's manager slack. http://randsinrepose.com/welcome-to-rands-leadership-slack/
Even if you only have time to lurk on that slack, the discussions have been incredibly illuminating for me!
I'm unsure if other Canadian cities use craigslist as much.
1. Tell everyone what you want and ask them for their thoughts I had avoided telling a few people because I thought it was too forward of me, that they already knew, and a few other excuses. Now that everyone (my team mates, my direct manager, other managers) know what I'm aiming for I'm getting a lot more feedback on my performance. Also I suspect some people are fighting for my promotion know that they know I want it. I kickstarted the effort with "catchup" meetings with everyone I could think of. I framed it as a "catchup" so I could also find out what challenges they were facing and how I could help them. I talked to QA leads, PMs and senior devs on my team and outside of my team. The few coworkers who were really excited for me, I asked if I could do recurring 1:1s with them. It keeps me visible to these people and I'm getting regular feedback on my work and the status of my promotion.
2. If someone says you will not be promoted, ask why and ask different people. I was told I would not promoted and I didn't fight it. But a month later someone else informed me of course I'm getting promoted but not until the beginning of the calendar year. I wish I had asked more questions when I was originally told no promotion would happen, it would have saved me a lot of upset/confusion/unhappiness.
3. Ask your departing manager to recommend your promotion to the director