Still a B Student

Now and then something happens to us all that reminds us we’re not perfect. I’ve written about the strengths of B Students before, and well last week I proved that sometimes I still have room to improve.

When I started this blog I set the goal of posting once a month. I have stuck with, or exceeded, that target except for two months since 2016. I missed September 2019 and last month. Last time around I set the goal of four posts in the following month, so that is my established case law.

I did have a piece written that I had planned to release. But it needed another editing pass. Before I got those edits done a project at work took over my life. I will have those edits done for next weekend, and I already know the general topic of the post what will follow it.

Last time the increased pressure to write actually resulted in some descent pieces. I wrote that B Student piece, which I quite like, in part as a response to that failure. Two others from that month are how-to articles that continue to get good readership years later.

Hopefully this will be an equally good month (although this post probably isn’t the best example of that).

Disable a Salesforce Trigger in Production with VS Code

I recently had to disable a Salesforce Trigger from a client’s production environment. Having discovered the need last minute for a project, I needed to react quickly and make the change quickly. Since the official documentation is a bit lacking I decided it was time for blog post of better directions.

The Salesforce CLI directions in the article above make a few annoying assumptions:

  1. That you’re happy to use MDAPI not SFDX.
  2. That all your tests pass in production (which should be true, but let’s be real it;s always).
  3. You enjoy working out CLI commands in a rush.

What you need

Disabling a Trigger Using SFDX in VS Code.

Connect VS Code to your target org. Easiest solution here is to just go to the command palate and authorize an org.

VS Code command pallet wit with SFDX commands shown.

Pull down the trigger from your org. I find it easiest to go to the metadata browser, find the trigger under Apex Triggers and click the download icon on the right.

Screenshot of VS Code org browser showing an Apex Trigger to download.

Update the trigger’s XML file to change the status. All project code files in SFDX are accompanied by an XML file of class metadata. Open the file and change the status to “Inactive”.

Screenshot of the VS Code file browser with the trigger's metadata file highlighted.
Navigate to the file in the file browser on the left in VS Code
Screenshot of code snippet emphasizing the Status XML tag and Inactive value.
In the editor change the status from Active to Inactive, and save the file.

Generate a Manifest file for your trigger. Right click on the trigger code file in VS Code’s file explorer and select Generate Manifest, provide the file a useful name (in this case used DisableTrigger)

A segment of the contextual menu to show Generate Manifest command's location.
Depending on your setup the context menu might be quite long, SFDX additions are generally near the end of the list.

Deploy the change. If all your org’s tests currently pass you can just right click on the new manifest file and instruct VS Code to deploy the source in the manifest to the org.

Another contextual menu snippet, now with Deploy Source In Manifest circled.

What if tests fail on trigger deploy?

While all our tests should always pass all the time, Salesforce admins frequently find that’s not actually true in practice. Heck this trigger could be part of that problem in your org. But to deploy a code change we have to run some tests. Since we are disabling this trigger, the trigger code doesn’t need to be in tests we just need to run a working test with enough coverage to get the job done. So go find a test class and then we can deploy.

VS Code doesn’t currently have a setting to set the testing mode on a deployment, so you’ll need to do this last step in VS Code’s terminal (available by hitting control-` if you don’t have it open already). In the terminal run the following command (replacing [good_tests] with the name of your test class).

sfdx force:source:deploy -x manifest/DisableTrigger.xml -l RunSpecifiedTests -R [good_tests]

It should deploy pretty quickly, but you can check the status by going to settings in your org and checking the Deployment Status.

Project Estimates Tool 2.0

A few years ago I wrote a piece about project time estimation and created an estimating tool. My goal was to get project managers to listen to the fact that estimates were inherently a guess not promise. The tool I created took a series of project tasks, the estimated time range, and a level of estimator confidence. It then ran a Monte Carlo simulation with those tasks, and generated a histogram of possible outcomes.

Five years later I still use it for project estimates. But I have grown tired of its interface weaknesses and needed to add cost estimation to keep it useful. So I recently heavily revised the tool and posted an updated version (the old version is still available here).

The interface is still very utilitarian (pull requests welcome), but this version makes it make easier to adjust the tasks. Much more importantly it now also estimates costs, not just time.

Histogram of time estimations
XY Scatter plot of cost projections, in a nice bell curve shape

The new version is faster than the previous. And it adjusts the graph type based on the range of possible outcomes.

Each task now includes inputs for min and max time, confidence, and hourly cost of that task. So if different people at different bill rates are part of the project it can still give you useful numbers.

The histograms broke down when faced with too many bars. So I settled on an XY scatter approach to help visualize the broader range that the cost estimator made normal.

Please give it a try, I’m always open to feedback, suggestions, and pull requests.

Costs Estimates

For this version I added the ability to include a unit cost for each task. The first tool worked just fine when you were estimating the tasks for one person who had one billing rate (or where hourly costs aren’t important). In practice teams need to be to able to do an estimate across all work streams, and different roles will have different billing rates.

This version includes a rate for each task and a graph of projected project costs.

Why I Created A Project Estimator

I wrote the original when I was struggling with project managers who would take any estimate you gave them as a range, pick a number, and promise the client (and themselves) we would hit it. To them an estimate was a promise – one that had to be kept. That lead me to badly overestimate projects so that the lowest end of my range would be a safe number – but that’s just a different form of bad estimation.

Histogram of time estimates.
This graph from the original version helped convince PMs that estimates weren’t promises.

I had a good amount of experience providing estimates, and had read a lot on the topic. I knew there were teams that did better and I wanted to help our team improve.

The original tool was loosely inspired by one Joel Spolsky described ten years earlier. He has several important ideas on his process regardless of your project methodology. But his idea of using Monte Carlo simulations had stuck with me since that article had been new. After failing to find a tool that included it, I wrote my own.

Are the Project Estimates Any Good?

Fundamentally the simulations are only as good as the estimates provided. For any project I have been able to compare my simulated project estimates to final hours my work fell within one standard deviation of the median.

The confidence measure helps more than I expected. Originally, I added the measure of confidence because I needed something to determine how often the simulator should assume people are just plain wrong – and by how much. While I could have hard coded a solution I did not know how to pick good values. I knew that my confidence varies by the task. I also knew the less confident I am the more I am likely to be wildly off. So decide to make confidence an estimator provided variable, and use that to pick the size of overruns.

For every 10% you reduce the confidence, the simulation will allow the upper bound of the estimate to increase by the size or the entered upper bound. On a task you estimate at 7-10 hours, a 90% confident estimate will allow overruns up to 20 hours (just in the 10% of times that aren’t in the 7-10 range), and 30 hours for an 80% estimate.

That extra box also immediately helped me feel comfortable with my estimates. Knowing that the simulator would offset optimism bias for me I could stop trying to do that myself. My estimates can use tighter ranges trusting the software to offset expected bias.

A Value of the Graphs in Project Estimates

The graph has turned out to be the most important feature. Initially I included it because I wanted to play with D3 and have something more impressive than numbers to show. What I discovered was a reminder of the importance of data visualizations – even simple ones.

As I said before I created this tool when working with project managers who simplified all estimate ranges to a single number and held everyone to that number. The first time I presented numbers from the simulator those project managers picked the median and complained I made it too hard. The median was better than what we had before, but not enough to treat as a promise.

When I started presenting the graph those same people immediately started to change how they talked about the project. By visualizing the impact of uncertainty over several tasks they could see that the project might run far over my estimate – or far under. The more uncertainty, the longer the tail on the graph.

Suddenly they were comfortable talking about risks from overruns, finding ways to help clients understand the possible risks, and being understanding when a task proved harder than expected.

The graphs tell the story, and empowers the team to have an honest and productive about project estimates.

Estimate your own project timeline.

Announcing Two New Snowfakery Faker Providers

For the last two years I’ve been fortunate to serve as a leader of the Salesforce Open Source Commons Data Generation Toolkit project. That project has produced and inspired a variety of efforts, including Snowfakery and a collection of starter recipes.

This week, along with my colleague Allison Letts, Salesforce’s Paul Prescod (the creator of Snowfakery), and our fellow project contributor Jung Mun, I helped create two new faker providers for Snowfakery:

What These Faker Providers do

The use of Snowfakery is growing. The more we use it, the more we want the data tailored to specific projects. And the more we find places where the Faker project’s providers do not have quite what we want. In particular the project does not (well did not) have providers for nonprofits and education specific data.

The Nonprofit provider currently just provides organization names:

$ snowfakery snowfakery_nonprofit_example.recipe.yml --target-count 10 nonprofit
nonprofit(id=1, nonprofit_name=Eastern Animal Asscociation)
nonprofit(id=2, nonprofit_name=1st Animal Foundation)
nonprofit(id=3, nonprofit_name=Upper Peace Alliance)
nonprofit(id=4, nonprofit_name=Southern Peace Home)
nonprofit(id=5, nonprofit_name=Unity Home)
nonprofit(id=6, nonprofit_name=Western Peace Home)
nonprofit(id=7, nonprofit_name=Upper History Foundation)
nonprofit(id=8, nonprofit_name=Upper Friends Committee)
nonprofit(id=9, nonprofit_name=Eastern Pets Center)
nonprofit(id=10, nonprofit_name=Northern Animal Foundation)

For the Education provider we have a bit more. You can generate college names, departments, and faculty titles.

$ snowfakery snowfakery_edu_example.recipe.yml
Account(id=1, Name=South Carolina University)
Contact(id=1, FirstName=Roberto, LastName=Stanton, Title=Associate Professor of Microbiology & Immunology)
Account(id=2, Name=French)

The providers can of course run as a standard faker community provider. Once you are setup with Faker just add the new providers with pip:

pip install faker-edu faker-nonprofit

Then you can use the libraries in your code:

from faker import Faker
import faker_edu

fake = Faker()
fake.add_provider(faker_edu.Provider)

for _ in range(10):
    print(fake.institution_name())
from faker import Faker
import faker_nonprofit

fake = Faker()
fake.add_provider(faker_nonprofit.Provider)

for _ in range(10):
    print(fake.nonprofit_name())

How we got here

A few months ago I posted on how to extend Faker to create nonprofit organization names. Allison took that as a starting point to create a similar project to generate names of colleges, departments, and academic titles (and a greatly improved phone number generator but that’s not included since it’s more general). Both of these projects were good proof-of-concept but were rough around the edges. So this week, with Paul’s guidance and Jung’s input, we contributed the more polished versions to the community.

During a virtual working session on Wednesday we restructured the projects, cleaned up code, added sample recipes for Snowfakery, and published them to PyPi. By publishing these as Faker providers on PyPi, and not as Snowfakery plugins, they are available to a wider audience. By having them owned by a larger open source community we are expecting them to enjoy long-term support.

Both are still just getting started. For example the nonprofit one still just generates organization names, but would benefit from job titles, program names, and more. The EDU provider right now just handles colleges, but is expected to generate other education related data in the future. We also have a plan for a third provider to help improve the diversity of the names generated by Faker to make our fake data more representative of real communities.

The Data Generation Toolkit project has been a great example of what happens when you bring people from a wide variety of backgrounds together to solve technical problems. Like the larger Data Generation Toolkit team Paul, Allison, Jung, and I all have different backgrounds, skills, and experiences. By coming together we are able to help each other find better solutions than any one of us would have found on our own.

It’s been an exciting week, and I’m looking forward to more to come.

Faith’s Joy

This is Faith.  Faith has found joy, happiness, and contentment – except when she needs her toenails trimmed, dinner is late, or she gets woken up for a nap.

Life for Faith wasn’t always easy. She spent a little time on the race track before they closed, and was among the last dogs to ever race in Florida. Her first adoptive home didn’t treat her well, and she bounced back to the rescue group underweight, with a cracked tooth, and uncontrolled multi-drug resistant worms. But those problems are gone (at least we hope, the worm treatment takes several months and we just got our first clean test last month – need three in a row). But Faith found a life she loves in our home. 

Two greyhounds cuddling on a dog bed.

She loves to cuddle with her brother. 

Greyhound in a room covered in shredded paper towel with a toy in her mouth.

She loves paper towels. 

Greyhound sleeping on a couch with her feet in the air.

She loves a good inverted nap.

Greyhound curled in a ball, sleeping on a chair.

She even loves hiking with us in the mountains of North Carolina (trust me on this one, she doesn’t hold still again until she’s napping when we are done).

Like many people I aspire to be more like my dog. She has handled life’s ups and down with grace (mostly) and forgiveness (graciously – even after I trim her nails). I hope to learn to be as openly loving as forgiving as her.

Build Cycles of Respect

In consulting we should expected developers to do all the same basic things as everyone else on the team. That includes supporting a culture of mutual respect with other team members.

We should explain our work clearly, be effective in meetings, and take feedback well. In consulting especially, we should engage with clients professionally, effectively, and happily. We should not be isolated off on our own teams working from specs we didn’t write, for clients we haven’t met. Basically, we need to be good team members and we can be expected to be that way. Developers, like most everyone else, do their best when when surrounded by people who treat them with respect.

One of the things I really like about my current job is that we have a respectful culture. It’s not that we don’t have disagreements, at times energetic ones, but we work through those challenges as a team of experts with differing perspectives. We are all expected to be experts who can collaborate with other experts, and to explain our work to clients.

Cycles of Disrespect

But that hasn’t been the consistent norm since I shifted to consulting. I have been on teams, and seen teams, that routinely insult the basic professional behavior of developers and other technologists. In those settings leaders made it clear that the standard of behavior was lower for developers than other team members. Most people I know end up adjusting their behavior to meet the standards set for them. Set a low standard of behavior get bad behavior.

I want to be clear that I have no intention justifying the harassment, bullying, and assault that is too common among developers (and more generally by men in the workplace) – that is not the challenge I’m addressing here (although I’ve addressed those issues before). There are behavioral problems in places that don’t permit and cover up that kind of behavior. Developers and other IT specialists are often still allowed to act as a grumpy trouble maker, or aloof superior jerk. We are told our brains work differently somehow allowing us and our colleagues to ignore healthy social conventions. And by allowing it, stating that we expect it, and taking no actions to correct it, we encourage that behavior.

Signs of Trouble

On more than one occasion, at more than one employer, I’ve been told things like:

  • “You’re talking techie now, I’m not listening anymore.”
  • “Developers hate meetings and never contribute productively.”
  • “You just have a thin skin and act defensive of your work when questioned.”

Often the person will laugh as they say these things like we have some kind of shared inside joke about some basic lack of professionalism. There are lots of reasons why people dismiss developers with those kind of statements, but that doesn’t stop them from being destructive.

When that’s your work environment, it’s tempting for developers to degrade to match expectations. Who takes feedback well when told upfront they have a thin skin? Who likes being in meetings with project managers who explicitly state their contributions aren’t welcome? What expert thinks it’s funny when you stop them and say you are not listening? 

This builds a cycle of disrespect between developers and their colleagues, dividing teams and impeding progress. When people are treated with disrespect while still performing critical tasks, I expect to see them act with disrespect is exchange. That is no okay, but it very human.

Breaking the Cycle

Respect is a two way street which makes it important to break the cycle on both sides. Everyone on a project needs to respect the roles we each have and the contribution we each bring. Those may be, and usually should be, vastly different across the team – otherwise there is no point to having a team at all.

As team members who are often in a position of some power – in part because we are hard to replace in the current job market – developers should take it upon ourselves to be the first to build respectful practices with colleagues.

We can, nicely, point out when we hear statements that feel isolating and rude. We need to try to understand why someone acts intimidated by the technical detail and find ways to help them along. Developers should make a point of soliciting feedback from team members and processing ideas with them. Everyone ought to build personal relationships across our teams to help improve everyone’s ability to work through hard problems (there is a bunch of research on this question).

Creating a Cycle of Respect

To build an ongoing cycle of respect take more than just breaking the old patterns. Developers are often in a position of leading by example and so that is a great first step. Asking friends and colleagues to make an effort with you will help build a re-enforcing cycle in a small group, which makes a great second step.

Understand that cultural change of an organization is hard, but usually it is possible on project teams. So it may help to start with just one team and making a real effort to improve communication and collaboration with the team. From there build out and try to draw others into your new patterns.

When teams work together well, understanding the project as a whole, they do better work. That puts everyone in a position to add ideas, raise concerns, validate suggestions, and adjust to changes.  When teams allow any member to work in isolation they losing the shared vision and project failure.

Being Nice vs Being Kind

A few years ago during a job interview at a nonprofit organization, the Executive Director asked me about the culture of the job I was leaving. He had noticed that I was stressing the importance of good feedback during my interviews and wanted to know why it was so important to me. Indeed, part of why I was job hunting was the job I had rejected the notion of mistakes – everyone’s work was always good. I told him that, and that I do my best work when I get honest feedback. He responded by drawing a distinction between being nice and being kind. He was sure everyone I worked with was quite nice, but they didn’t sound very kind to him.

Being nice when giving feedback just means saying positive things.
Being kind when giving feedback requires helping another person understand how to improve.

It was one of those moments in life where someone offers you words to explain a struggle you’re having and suddenly things make more sense. I knew I was unhappy in the job, but his insight brought into focus the reasons I wasn’t fitting in. Being told my work was great did not mesh with my understanding that it’s important to admit we all make mistakes and find ways to avoid repeating them. My desire to examine my own work caused conflict, let alone my efforts to introduce peer feedback.

The CEO at that job once told me that if people heard their work wasn’t perfect, they wouldn’t want to come in the next day. He didn’t seem to realize that getting dishonest feedback causes the same thing. And seeing no chance for improvement was even worse. There was no room to revisit problems that lead to near failure and ongoing technical debt for the client. Instead they convinced clients the technical debt was a feature, and used it to sell support contracts.

All the feedback my colleagues and I got was nice to hear (“This is great.”, “The client will be thrilled”). But unrelenting positive feedback didn’t help us improve as individuals or as a team. Our leadership gave team members a false sense of success and held the company back from improving.

The thing about being kind, is that sometimes you have to tell people things they don’t want to hear. That can be hard, and to do it well requires you to care about the other person. If want people to like everything you say, it will be hard to be kind.

Giving nice feedback involves offering a string of hollow platitudes that leaves people with a false sense of achievement. That makes people vulnerable to failure when they move forward without understanding their weak foundation. Giving kind feedback requires you to provide an honest assessment of a person’s work and helping them recognize errors. Kindness requires listening to people when they push back, and finding ways to help them find ways to excel as they move forward.

When all was said and done the opportunity wasn’t the right fit for me. Turning down their job offer was probably the hardest career decision I ever made. But they and I left good enough impressions with one another that I recently started serving as an volunteer advisor to the program I would have been running. That service has allowed me to reaffirm my sense that it was the right decision not to take the role both for me and for the organization.  And it has given me a chance to help give them some kind feedback to help – I hope – improve their operations. I try to be as kind to them as an organization as they were to me as an applicant.

College Advice from a Professor’s Spouse

My wife is a college professor. That means, in addition to being married to a very smart person, I also get to hear lots of tips and tricks about how to do well in college – particularly this last year with my wife doing office hours from home on video from her office just outside our kitchen. So as a service to all those headed off to college in the fall (including our oldest nephew), students already working to complete degrees, and to all the professors and instructors out there, I thought I’d offer a few pieces of college advice I’ve picked up as a professor’s spouse. I’m also blending in a few things I learned getting my own degree and from working professionally with colleges on a regular basis (basically, if you don’t like anything in here, blame me not my wife).

The first two are so painfully obvious I hate to have to tell them to people:

  1. Read the syllabus.
    I mean actually read it, not just look at the words (although that is a start). 95% of the time the professor will literally tell you exactly what you need to do to get an A; or if you’re smart and lazy it lays out how to coast to a C. Heck sometimes they even give you extra credit just for showing signs of reading it because they know most of your classmates won’t bother.
  2. Read all the instructions.
    Your professors want you to succeed. Their lives are better when you do good work. They like seeing students learn and grading good work. So for each assignment they give you instructions about what you need to do to get a good grade. Read and follow those instructions.

Okay now for the advice that’s not so obvious and may be harder to follow.

You earn grades, you aren’t given grades.

Your grade should reflect the work you produce in that course, in that semester, for that professor. You aren’t entitled to a good grade unless you do good work by the standards set for everyone in the class. If that’s not happening – well I’ll get to that in a minute. But don’t confuse a hard assignment, or a professor with high standards as a lack of fairness. Grades are fair as long as the professor holds everyone in the course to the same standards.

Also remember professors should not lower their standards just because you are majoring in another subject. Your philosophy grade should reflect your philosophy course performance even if you are a math major (and vice versa for the philosophy majors). Complaining that the assignment is unfair because you don’t write clearly is the wrong way to move forward – ask for help writing better when you need it.

Complain to your friends, not to your professors.

As I just said: yes, sometimes an assignment is hard. Yes, some professors make it hard to earn A’s. Sometimes you stay up all night, work so hard it physically hurts, and your paper earns a D. These are all great things to complain about to your friends, on your own time, in your dorm or apartment. I did in college, so did my wife, and all our college friends – that’s part of college and the learning process.

DO NOT:

  • Complain to your professor that the assignment was too hard.
  • Stand in the hallway outside their office and rail at the injustice of it all.
  • Complain to your other professors.
  • Rant on social media about how it was hard to study cause you were really drunk. (Seriously, professors can see the stuff you post on the school Facebook page – stop it! Aren’t you all supposed to use other platforms these days anyway?!?)

Remember that your professor knows how all your classmates performed. They may know some of your classmates started that paper two weeks ago, asked for advice along the way, and earned an A. They already know if an assignment was actually too hard (it does happen) and almost certainly took that into account when assigning grades.

Hard work and good work are not the same thing.

That paper you stayed up all night writing was probably hard to complete on time, and not your best work. Just because it was hard to do, doesn’t mean you did it well. In your non-college life this is most obvious in things like physical engineering and computer programming. If your phone’s app crashes all the time, it’s bad. If the bridge falls over, no one cares if the engineer was up all night checking their math. It’s also true on standard college work like papers and art projects – if your picture is overexposed or your paper poorly written the outcome was bad and the grade you earn should reflect that reality.

Ask for help – do not demand special treatment.

Most of the people doing classroom instruction in most colleges like helping students succeed (research professors can different – although not all, and you shouldn’t assume they don’t care). They have office hours so you can easily find them to ask questions. This is not so you can easily yell about your grades. Professors do not take well to being yelled at, threatened, and generally treated as if they are supposed to “give” you anything. Remember, you are not an education customer and the professors do not work for you. Never tell a professor you pay their salary; you don’t, and saying it won’t help matters.

Professors all know how to ace their classes. They should, they designed the class after all. Professors understand all the material they are teaching you (even if you don’t feel like it sometimes) that’s how they earned those advanced degrees – probably at a deeper level than you realize exists. If you are confused or struggling they are the best source of help around. They are good at this stuff – give them a chance to help you get there too.

Exceptions can, and sometimes will, be made.

Sometimes a professor they might cut you a break or offer extra help if you ask. But these favors should be asked for rarely and very carefully. Try to understand what you’re really asking them to do for you. Exceptions for you might be deemed unfair to others in the course and have to be explained to a dean. Changes in deadlines, taking incompletes, and other accommodations may require the professor to do extra unpaid work.

When I was in college I wanted to leave early one semester, to attend an international conference. Of my four courses that semester three had open-book exams or projects – so I just finished those before the deadline. The fourth was a Government course with a traditional exam. The professor was excited about the event, so he was willing to let me take the exam early.

That exception required him to trust me not to share details or to write a second exam just for me – neither are trivial requests. If I had asked to take an incomplete, so I could finish late instead of early, I would have been asking him to do even more work. Often that kind of extra work goes unpaid.

I didn’t have a lot of interruptions, and my exception was for an opportunity, not outside interference. I know not everyone is so lucky, and you may have good cause for asking for exceptions to course rules more often. But if you find yourself asking for those exceptions more than once a year, consider talking with your advisor or the school’s academic success center. Asking for too many favors is either a sign you’re expecting special treatment or need support finding a better overall life balance.

Note: Many schools offer some form of hardship accommodations for health challenges and other major life disruptions. Using those when you need them is not asking for a favor. Those are policies meant to help you succeed, not exceptions to the rules of a course. Check your student handbook when things are easy to understand how that works in case something goes really wrong.

Your classmates lie – a lot – so you have to prove you are different.

That syllabus I told you to read (seriously most important thing here – read it), is probably long and boring. Filled with classroom policies, honor codes, assignments, deadlines, and more. When I was in college they were 2-3 pages and nearly all about the assignments. My wife’s, and her colleagues’, have grown from there into a 10 page tome of policy. They hate it. You can also hate it. You should blame every classmate who goes to a dean arguing over a loophole they think they found. Expect that a new rule is written every time you hear another student say some silly thing to justify obviously bad behavior – particularly if sounds unfair to you and then works for them.

Every one of those rules you see probably has a specific former student to blame. Your professors would love to save time and energy by going back to having a 2 pager of assignments and deadlines. Trust me, they sit on my back porch and lament about it – while sharing suggestions about how to describe how often it’s okay to pee during an exam or whatever thing has come up this time.

Exam Tip: pee before the exam. If you cannot regularly go 90 minutes without a bathroom break, and don’t know why, check with a medical professional. After you do that, read the syllabus and student handbook again to check for policies on medical accommodations.

Yes, you may need to prove your loved one died.

If this happens to you, first and foremost, I’m sorry. Your professors are sorry too – even if they don’t show it in front of you. But students lie about this all the time. It goes in and out of fashion as the lie of choice, but it’s always around. It’s called Dead Grandmother Syndrome. There are actual studies on it (even if entertainingly written, it uses real data). That’s why your college has an actual procedure to report the death of a loved one.

My wife’s colleagues all have stories about assignments that were due just before a break that caused a wave of ill-health and death in student families. I think my wife’s record is 5 grandparents with one paper – her record is not very high. If an assignment is due the Wednesday before Thanksgiving or the day before Spring Break, a single paper might wipe out a dozen grandparents (usually grandmothers – see references above). Those people who wanted to leave for vacation a day early are why, when your life actually sucks, your professor may remind you to complete your school’s process.

That said, if you build up trust with you professors by being a reliable and good student, they will probably try to help you first and worry about the paperwork later.

Learn your college’s grade appeal process.

While we’re one the topic of policy let’s talk about times there are actual problems. Sometimes your professor is a jerk and is unfair. This is genuinely pretty rare, but it does happen and it’s bad when it does. Your college has a process for this. I don’t know what that process is, but it’s there and it’s probably in your student manual. Look it up it. Follow it. I can promise you it does not involve your parents calling anyone at the college – if that’s part of your (or their) plan, start again.

If your professor crosses lines beyond being unfair with grades, at least in the U.S., your college is required to have a policy for that as well. But it will be easier to deal with the process if you have support. Go see a professor you like and trust and ask for help. If you don’t have a professor you are comfortable with check to see if the school has a student advocate, or try calling the counseling center to see if they can point you in the right direction (and consider if their direct services might be useful as well). Those are serious situations, and you deserve more help and support than I can offer here.

Professors make mistakes.

Professors, being humans (this fact seems to surprise students when we see them in public), make mistakes (this fact surprises no one). When you think a professor made an actual mistake, don’t be a jerk about it.

During my first programming course in college I got a notice in my mailbox announcing that because I’d failed the first test I should drop the class and change majors. I was pissed. In no small part because I had been disappointed in the B- I’d earned on that test – not what I wanted but a long way from failing. I could have stormed over to the professor’s office and raised my voice to demand justice. Or I could have gone to the department chair and insisted he intervene on my behalf.

Instead, I waited until scheduled office hours, and went to talk calmly with the professor about the situation. I took the test with me – which had “B-” written in his (not my) handwriting on it. I started the conversation by pulling out the exam and handing it to him. He looked at it, cursed at himself, and noticed the off-by-one error in his grade book. He then apologized and offered me a job.

If I’d gone charging in I fully expect I would have gotten my grade fixed, but I would not have gotten a job (I also became his dog sitter so I got free food and laundry service every time he traveled for the next three years because I wasn’t a jerk). And he would have remembered me being a jerk about a simple mistake in every course I took from him until I graduated (there were several). Instead he liked having me in class, which is never a bad thing.

Your professors are nice people.

Seriously, when there aren’t world-wide pandemics they come to my house all the time. I meet them at parties and conferences. We have a good time together.

I’m not saying this just because I am married to one. Sure sometimes they get a little too into their subjects, or lack some social graces, and yes they hold power over your grades. But in the end they are just people like everyone else.

Take them seriously. Listen to what they have to say. Read their syllabi. But don’t lose track of the fact they are person, with a life off campus, a family, hobbies, struggles, and all the rest of it. Ask them open ended questions before or after class and you might learn a few extra things worth knowing.

Good luck and work hard!

There are plenty of other things you need to do to get through college, and lots of other advice to read. But hopefully these tips will help you along the way.  Good luck this year. Hopefully it goes at least a little better than last year did (for all of us).

SC DUG July 2021 – Queries on Queries

For the July 2021 SC DUG, I gave my new talk titled “Queries on Queries” which poses questions to ask yourself when migrating data between systems. Data migrations are often critical to project success, but all too often that are treating as a throw-away process. This talk is intentionally platform agnostic building from my experience with both Drupal and Salesforce.

If you would like to join us please check out our up coming events on MeetUp. You’ll find our meeting times and, once you RSVP, remote connection information.

We frequently use these presentations to practice new presentations, heavily revised versions, and test out new ideas with a friendly audience. So if some of the content of these videos seems a bit rough please understand that is some of the point. If you want to see a polished version checkout our group members’ talks at camps and cons.

If you are interested in giving a practice talk, leave me a comment here, contact me through Drupal.org, or find me on Drupal Slack. We’re excited to hear new voices and ideas. We want to support the community, and that means you.

SC DUG June 2021 – MQTT and Drupal

In June for the SC DUG meeting Will Jackson from Kanopi Studios gave a talk about using MQTT with Drupal to connect to local IoT devices. A fan of home automation, Will has created a Drupal 8/9 version of the MQTT module. He is hoping to encourage more people in the Drupal community to join the fun.

If you would like to join us please check out our up coming events on MeetUp. You’ll find our meeting times and, once you RSVP, remote connection information.

We frequently use these presentations to practice new presentations, heavily revised versions, and test out new ideas with a friendly audience. So if some of the content of these videos seems a bit rough please understand that is some of the point. If you want to see a polished version checkout our group members’ talks at camps and cons.

If you are interested in giving a practice talk, leave me a comment here, contact me through Drupal.org, or find me on Drupal Slack. We’re excited to hear new voices and ideas. We want to support the community, and that means you.