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.
Changing on the Job: Developing Leaders for a Complex World by Jennifer Garvey Berger
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.
There are increasing number of reports in Canada that Indigenous Women were forcefully sterilized in the last few decades. Women who gave birth in hospitals had their tubes tied after giving birth. I agree this is a one of "the worst forms of racisim/ethonicide/genocide". And yes, I dont understand why more (white) Canadians are not aware of this, and why there has not been a larger out cry over this.
https://www.cbc.ca/news/canada/saskatoon/report-indigenous-w...
[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.
It depends - I don't think there is an true answer to this question.
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 dont have an exact book or course to recommend, but rather how to approach school courses...
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 liked how to worded "emotional separation"
The reduction in my stress has been amazing, especially considering we've been in the middle of covid. My moods are way better regulated now. I'm no longer trying to ignore my angry office mate who's muttering under his breath. I didn't realize how much upset people influence my own mood. I thought I was good at ignoring angry people, but the action of ignoring took up a lot more energy than I previously thought. My biggest worry about back-to-office is how I'm going to managed my increased stress levels.
I'm going to guess most people here had short hair while in elementary school...you're all so lucky!
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.
There is also a whole host of mental illness that are triggered by physical immune responses. Eating disorders that stem from one bad diarrhea episode are a really common example of this. Both ends of this spectrum can result in bad mental health.
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.
You may want to consider a new employer. Although the average company does not care, the good companies and good managers should care about supporting you! The "let them figure it out on their own" approach is even more common for folks who dont fit in the company culture. I've seen some juniors have a hard time and others not, because a manager will "click" more with one than another based on their own bias (oh he still lives at his parents house, he's weird vs oh he goes fishing like me, i dont mind helping him).
Personally I feel terrible that I work in an industry that does nothing to support people. I've struggled through jobs with no support (and worked wayyy to many hours to make up for that). If you have free time, I would suggest job hunting as a "see what you can find" adventure. You might get lucky and find much better coworkers.
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!
You describe almost exactly how my team approaches our development. We are ~80 developers on a single web application. The core team deals with the landing page (to put it simply) and the other teams (5 to 10 devs per subTeam) deal with their own section. When we first started this project there was a UI team that was made up of one developer from each subTeam. This ensured that as UI work was done it was consistent and each subTeam knew about the available UI controls to use. Something like a datepicker took a lot of back'n'forth between everyone, but we're a few years in now and our UI controls are pretty stable. We also had a lot of decisions around "this is what a data-entry form looks like" so the basic CRUD workflow on each team is pretty similar. We also aim to all use the same 3rd party libraries (ie one dateTime library, one webpack configuration for everyone, etc). It was a lot of decision making and a lot of time spent making a shared understanding, but worth it in the long run.
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 :)
Look at enterprise software jobs!
A lot of enterprise software is massive old code bases that need people who are good at spelunking and understanding "what was this doing and what is it doing now". It might not be 100% refactoring, but a lot of the customer bugs that come in are caused by tech debt and the solution involves refactoring a tad. Even if the software is still growing with new features, there is a lot around refactoring existing code to fit in the new feature.
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!
[1]
Honey is bad if you've got issues digesting fructose.
For someone with IBS, or another digestive issue, the FODMAP diet recommends no more than 1 teaspoon of honey with a meal (ie every 4 hours). The FODMAP diet tracks fructose-in-excess-of-glucose as that is one of the common triggers of digestive issues. Its not saying that honey is unhealthy, but rather honey causes issues for some folks.
As someone with IBS, Fructose in excess of Glucose is THE issue.
The FODMAP diet (peer reviewed, currently the gold standard for IBS diets) is about reducing the fructose-in-excess-ofglucose. Only a teaspoon honey at time, but you can eat maple syrup. Greatly reduced consumption of stone fruits.
Its known that some IBS cases are caused when someone does not breakdown fructose in their small intestine, so the fructose then ferments in the large intestine. You want some fermentation in your gut, but not too much!
My employer started using microservice as a way to update technology. We didnt have time to rewrite the main app, but new features were written in microservices, and those services used new technology. The savings wasn't a number, it was quantified as pass/fail.
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!
This!
Find good coworkers, good team mates, any one who is willing to communicate with you.
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.
I am a Cdn on a TN. There is very much an expectation that you will reside in the same location of the office. Its not as hard+fast rule (like the h1b1) but considering a random border guard could have a bad day and deny your TN based on whatever they feel like, I would strong caution against anyone living far away from their assigned office.
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.
Do as much communication as you can over email and IM (rather than verbally). Its easier to document and personally I find people are less like to cuss when typing. Also, if possible, move your seat as far away as possible so its harder to chat.
Also, cc your boss in emails. Use the excuse "keeping Boss updated with my work status". This gives you more documentation that you told your boss of the problem (and the cost of the problem) and received no support from him.
Even if you don't plan on going to HR/CEO, documentation is important to collect. It will protect you if the abuser suddenly blames you for the abuse.
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.
I agree. I would say that is the difference between a junior and a senior dev. "Spearheaded the adaption of unit tests, increased coverage from 0% to 90%" for a senior dev.
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!
I would like to echo this.
The statements on the resume should be "did x which caused y". The caused y part should be how valuable your contributions were. The more concrete you can write the better.
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"
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.