Ducks look graceful and smooth on the surface, and kicking frantically underneath.
If, like me, you love talking about tech, you may find it hard to speak to clients and managers who don’t. So I try and follow one simple rule.
Let go of the detail.
Have a summary that skips over it, because generally the people you talk to trust you on the detail. If you’ve ever had a boiler installed, they’ll never tell you what pipes they’re using, how it’ll context to the power supply. You agree on the boiler model and the installation date, and let them worry about the detail.
Sure, record the detail for yourself and your team, but make it available on-demand, not as a fire hose.
There’s a lot of information out there. And more generated every day than you could process in your lifetime. So you need to filter out the important nuggets and discard the rest. The most important thing is what you ignore, because you’ll be ignoring most of it.
Many productivity frameworks deal with this problem the same way. Take the firehose of emails, RSS feeds, Twitter recommendations, that book at the meetup, … and collect them in one place (or, if you really must, 2 – one physical, one digital).
Only add things that look interesting, and be intentional about it. Not every email or every tweet, just the ones you’ve marked (IFTTT or Zapier are a great help here). That’s your first filter.
Then, at a scheduled time, on a regular schedule (weekly or fortnightly) decide what you’re doing with everything in the one place. That’s your second filter.
Then, for the things you’ve decided are important, review them, rewrite them, record them. Your words are the next filter.
And don’t be afraid to rewrite, to delete. I use git for my notes so I know I can keep things clean and look at the history if I need to.
Or, to put it another way:
Put everything in your Universal inbox (Trello, Evernote, Notion, …) – one place for “this looks interesting”, from web, photos, videos, etc. but only what you’ve chosen to put in. Don’t let another person or an algorithm choose for you.
Automate the copying, not the decision to copy.
Each week, for everything in your inbox, make a decision.
👉 Either “this is useful” – archive and tag 👉 Or “this is actionable” – add to task list 👉 Or “why did I bother with this” – bin it
Split tasks into “now and next” and “coming up”
👉 “now and next” is stuff planned until your next horizon (tomorrow, next week, next sprint), 👉 “coming up” is the rest of the stuff important from your latest planning session (this week, this month). 👉 Everything else is unimportant right now, and either is in the ideas archive waiting to be promoted when the project is attached to resurfaces, or is dated to surface at the right time (e.g. annual subscription)
🚫 If the user doesn’t currently exist, return 404 – this informs the caller that nothing can be done with this resource until it is created or recreated.
🙈 If the user exists, but we want to protect against username enumeration, return 404 – this removes a route for malicious agents to identify actual users, perhaps prior to a password brute force. They may decide this endpoint is less likely to have the full protections afforded to the login endpoint. This endpoint should also avoid indirect enumeration, for example returning immediately for “user doesn’t exist” and delayed for “user exists but we’re pretending because security”
🔒 If the user exists but the caller doesn’t have permission to see their appointments, return 403 – caller will have to login, or ask someone who has access.
Empty time
Given the selected user exists
🔐 If this user does not support appointments, return 404 – these resources can’t be found.
🗓 If this user does support appointments, but there are none, return an empty list.
note : some APIs will return 204 No Content in this scenario. 204 should only be used for POST or PUT requests to indicate server action was a success, and there’s no data to send back
Empty space
Given the selected user exists And they have at least 1 valid appointment (see business for what “valid” means)
📺 If the appointment has no location (because online conference links are saved elsewhere in the appointment body) then no location property should be returned
❔ If the appointment has no location (because it is unknown) then the location property should be returned with no data (the empty string)
In a well-managed software environment, you’ll have a mentor to help you get up to speed with a new project. But that doesn’t always happen. So here’s some tips I’ve picked up about how I onboard myself onto a new project.
Always ask questions.
That’s how to understand documents and code. If it seems like something obvious, ask a rubber duck first, but on my team, I always prefer the developers who ask for help when needed than the ones who struggle along in silence.
For big documents, always expect to send a clarifying follow-up. Write notes and questions as you go through. Some things will be answered, even if not in the order you expect, but reviewing the document shows you’re taking it seriously, and you’ve taken time to process it.
Rewrite it on your own terms
I’ll tend to write notes about the business domain, possibly a glossary, as well as key concepts that will inform how it needs to be built, such as the main user flows, any special rules around security or performance, or specific highlights that meet the project goals (i.e. the high-level view of what must the project have to be successful. Sometimes it helps me to draw diagrams for the flow, or for the connections between different parts of the system.
Ask more questions
For other questions, a good rule of thumb would be if you can’t figure it out yourself or via Google (or project docs) within 30-60 minutes, ask someone else.
.net is a battleship, and it’s taken a long time to change everything to core, and figure out what the Framework/Core future is. In the meantime, you may have found your project crushed in the path as new APIs change or old technology gets deprecated.
Ask Java developers about where Oracle is taking their language and you’ll hear a similar story. The future is different. Maybe better, but in some places definitely worse.
Change is inevitable. That’s why our industry has embraced agile, so we’re ready to change on weekly or monthly cycles, not yearly ones. The longer it takes to make the decision to change, the more baggage you have, and the harder that change will be. That’s why Jez Humble recommends “if it hurts, do it more often”. That change may come from the business, from the competition, from the platform, or from the environment. How did you deal with Heartbleed, or Spectre? How many of your customers are still vulnerable, and are reducing herd immunity for the rest? Are other companies carrying your baggage without knowing it? Are you the reason that IE6 VMs are still a thing?
The bleeding edge is painful. .net Core broke things, Angular 2 broke things, Python 3 broke things, Edge broke things. But not keeping up breaks more.
When I was a tutor at university I remember one student who I only saw towards the end of the year. I think computer science was their additional course. They came in after apparently spending the best part of a year learning Java, and sat down to complete their assignment.
It didn’t take long before I was called over to help. Their code wouldn’t compile. A fairly standard console application, with some output. And no semicolons.
I was incredulous, and as a young eejit, I’m not sure how well I hid that. I couldn’t believe someone could have completed the lectures, read the books, and completed the previous 29 assignments without using semicolons.
How could they spend a year on a Java course and not learn anything?
Regrettably, I refused to help them and pointed them towards the obvious and clear error messages that they’d obviously been looking at before they called me over.
I wasn’t going to build it for them. I couldn’t teach them 1 year’s coding in 15 minutes.
And yet, they turned up. They asked for help instead of struggling on. Exactly the things I’d wish for in my new starts when I started leading teams and onboarding staff.
They knew the shape of the solution and they knew where their talents were. If I’d been a little more patient, I could have nudged them gently on. But I don’t know if that would have been enough.
If you are mentoring or leading developers, are you stepping in early enough? Are you praising effort and being vulnerable enough to ask for help? Can you see their strengths and weaknesses? Are you giving yourself enough time with them?
Are you being the senior that you wish you’d had when you were a junior?
Thanks to everyone who came to Scottish Developers to see myself and Christos talking about identity. If you missed it, be sure to watch again on YouTube. Many thanks to Carole and Andrew for getting Scottish Developers back and running again.
During the session, a few questions came up that I want to put here for the permanent record.
Pop-up vs redirect flow
If you were watching myself and Christos closely, you may have noticed that I was using the redirect flow in my examples, whereas Christos, and most of the Microsoft examples, use the pop-up flow.
The key difference here is that the pop-up flow leaves the app intact, does the auth in a separate window, then returns the token to the app from JavaScript. The redirect flow leaves the app, does the login, then redirects back to the app.
The popup flow is thus easier to develop and work with, but it doesn’t work on browsers with strict pop-up settings. I’ve had to change Firefox to get it working, and I’ve never seen it work reliably with an iOS or Android browser. If you need to support IE, MSAL will fallback to redirect flow anyway.
To get the redirect flow to work reliably, you need to be able to restore state when your app gets reloaded. The best way to do this will depend on your app, but common methods would be to persist state (or just current route) in localStorage if there’s nothing sensitive, or pass the current route/state as a data parameter to the login call, and this will be returned to your callback URL, for you to handle appropriately.
Storing Access Tokens
Access Tokens are your secrets. Treat them as securely as passwords. Don’t use local storage for access tokens.
DON’T USE LOCAL STORAGE. DON’T USE LOCAL STORAGE.
Best option is to keep them in memory, and rely on the browser process sandboxing to keep the secret safe.
As Christos mentioned, if you use the MSAL library, it has its own credential cache that will handle this for you.
Passwordless login
If you can, definitely prefer passwordless login. Chances are your website, or your intranet, isn’t important enough to your users for them to create a unique, secure password. Azure AD supports passwordless as well as 2FA and Hardware auth (including biometric on supported devices).
Yes. For backend services that don’t have an interactive login (such as timer-based jobs), and can keep the secret secure. However, where a service supports it, please use the Managed Principle approach as shown by Christos. If the service never knows the password, it cannot lose it. Let the identity provider grant trusted access on demand.
Where there is an interactive component, the OAuth flow allows the user to verify and control access to whichever subset of their data they choose.
Craig Nicol 