(a series of tweets originally sent to @ArrieLay and stored here for posterity…)
Fake it til you make it. Always act like you know what you’re doing, cos You DO – You’re being imperfect, just like everyone else.
Pay attention to people. Focus on empathy. Learn to pair. Learn to collaborate. Celebrate and enable your fellow team members.
Always come to work as yourself. Don’t be afraid to show vulnerabilities, and give others space to show theirs too.
Take risks. Relish your uncomfort zone.
Remember that EVERYBODY feels insecure about their knowledge levels. It’s impossible to know everything, and everybody thinks they are disadvantaged because others know more than them.
Learn to embrace your knowledge gaps. See them as exciting opportunities to learn more. Never be ashamed of them.
Have a questioning attitude, be open about your excitement about learning more. People respond well to it and will help you learn.
Love people. Even the annoying ones. People are great. People are useful. People will help you, whether they mean to or not. 🙂
And for the older amongst us… Age is an advantage, not a curse. Find the wisdom you forgot you had. Age is money in the bank.
Here are some links to some helpful resources for women arriving at or returning to careers in tech: https://insimpleterms.blog/2017/10/13/resources-for-women-arriving-at-or-returning-to-it/
Just a bunch of links really, but hopefully useful…
Mums in technology:
13 places where women can learn to code: https://learntocodewith.me/posts/13-places-women-learn-code/
Code First Girls: https://codefirstgirls.typeform.com/to/ks4bsj
Code First Girls professional courses: http://www.codefirstgirls.org.uk/female-professionals.html
Specificity is what you use to determine which bit of styling will “win” when there are conflicts. It’s all about how specific your styling is in defining what elements it should be applied to.
There are five different levels of specificity, with most important at the top:
- Wherever this is, it wins
- It’s BAD. Avoid. It makes a mockery of any other css rules, and makes your css v hard to read / debug.
- Inline styling
- (use of the Style=”” attribute within an html element)
- Id selector
- !! Remember, this means that your html element has an Id, and you are writing styling which will only apply to that one html element with its own unique Id
- This means your css will not be reusable!
- Class, pseudo-class or attribute selector
- Element or pseudo-element selector
- So, if there is some styling which uses a level higher up the tree, it will win
- If there are two pieces of styling at the same level, this is how you decide which will win:
- Whichever one uses the most selectors at that level will win
- So, div > ul > li > p will beat div > p
- If they use the same number, then the one defined most recently (eg lower in the file) will win
- css-tricks.com uses a numbering system to represent the above levels, eg (0,1,0,3,0)
- The universal selector (*) has no specificity value (0,0,0,0,0)
- Pseudo-elements (e.g. :first-line) get 0,0,0,0,1 unlike their psuedo-class brethren which get 0,0,0,1,0
- The pseudo-class :not() adds no specificity by itself, only what’s inside it’s parentheses.
- The !important value appended a CSS property value is an automatic win. It overrides even inline styles from the markup. The only way an !important value can be overridden is with another !important rule declared later in the CSS and with equal or great specificity value otherwise. You could think of it as adding 1,0,0,0,0 to the specificity value.
More here (this was where I made these notes from): http://css-tricks.com/specifics-on-css-specificity/
Also more here: http://www.smashingmagazine.com/2007/07/27/css-specificity-things-you-should-know/
This list is culled from a thread where people were asking for useful resources when learning Git. A lot of useful recommendations were made, so I’m summarising them here (for my own benefit as much as anything):
I ran a git workshop for some devs earlier this year – I created a repo, a bunch of exercises and some top tips. Everything you need to find your way around should be in the readme: https://github.com/claresudbery/Git-Playground
I find it very helpful to understand what the definition of a branch is: it’s just a commit, which defines the current head of the branch …and that allows you to explain the concept of “detached head”.
I would also encourage people to dig a little into the gitconfig folder and understand what diffs and commit IDs are all about.
When assessing third-party products to purchase their software products:
- Products need to be cloud native, extensible, and use open standards for integration.
- How quickly do updates move from development to production? Do they use CI?
- What do their processes look like?
- What sort of extensions do they provide?
- Do they allow you to customise a product without going off the upgrade path?
- How will you migrate your existing data to the CRM solution?
- Is data security guaranteed?
- Does the solution have regulatory compliance?
- Can you have a single central identifier for each customer, that can be used across systems?
- How will communication happen between systems?
- Does the vendor give good support?
- Are their APIs fit for purpose?
- Will they give you all the access you need?
- Will they respond quickly to attempts to communicate / collaborate?
These are my notes from a session on what a tech lead needs to do and know when arriving on a new project. The wisdom came from @JimBarritt at Thoughtworks – I am just the conduit.
Note that this list applies both to projects that existed before the tech lead arrived, and those where the whole team / product is new.
The first two are apparently “the two most likely causes of death or injury”:
- Where’s the production environment? It’s the most important one! What does it look like? When will it be ready? (Development environments are an afterthought after prod)
- How are we going to go live? What’s the plan?
- Load balancers
2) Third parties
- If environments beyond your control are chaotic, it’s even more important to make sure your own environment is super-organised and disciplined, smooth, automated, with good scope planning, etc
3) Find the movers and shakers
- Find all the people who can say No, and the people who hold the purse-strings/can sign off budgets, and the people who can say “Yeah, you did a good job” and get to know them
- The person who has control over data protection (Beware “organisational scar tissue”)
- In the public sector, the SIRO (Senior Information Risk Officer)
4) Find any top-level documentation of your team’s work, read it and understand it
5) What’s the budget and the value proposition?
- How well defined is it? Why are you doing the work? What’s the vision? Do people understand it?
- Once you find this info, be really repetitive about it
- If there are assumptions which are crucial to the whole success, keep repeating them at the start of every showcase
6) Try to have a one-to-one with each person in the team
- Try to understand what their goals are, particularly on the project – and be transparent about your own goals. For instance if you have areas you want to move away from, find people who are keen to move INTO those areas
- What are their main pain points and blockers?
7) Befriend a project manager and get to understand how they manage budgets
8) If there are multiple teams, find and get to know the other tech leads
9) Understand the importance of the Trinity of delivery: Delivery manager, product owner, tech lead
- There is often a tension between these three areas
- Build relationships with these people
- All three should be present for all decisions, otherwise it’s likely to be skewed
- Tech leads can sometimes get a bit side-lined in these relationships
10) Backlog: make sure the scope is clearly structured
- Use story trees and backlog hierarchies
- People can struggle with higher levels of grouping / scale
- You need to get into the helicopter, go up and look down on the thing you’re building
- Make sure you have access to it
- Remain connected to it
- Get a couple of the devs to give you a guided tour
- Can be particularly illuminating to get newer team members to do this
- You need to be able to visualise the entire code base (overall architecture)
- How easy is it to run it from scratch for the first time?
12) What are the pain points and blockers?
- Project manager is good person to talk to about that
13) Cross Functional Requirements
- Resilience & scalability
- Is it going to fall over with the load
- Is someone going to break into it?
- Although automation is awesome, don’t fall for the trap of thinking you have to set everything up at the start
- Don’t necessarily prioritise automation – but do prioritise what you need to actually deliver something
- Once you have something up and running and iterating, it’s all good – but how do you break that initial blank sheet of paper?
- You want pipelines etc, but as a principle, maybe there are different laws of physics right at the start of a project
- Don’t spend six weeks building a pipeline with no actual deliverable – make sure you have something iterative
- Imagine this product that you’re building… imagine you’re doing it with no software at all. Then bring the computer into it, and ask why – what is it going to give you? Where can it give you the most value? Don’t add stuff you don’t need
- Imagine a walking skeleton in business terms – for instance, delivering whisky by physically posting it*. Your deployment walking skeleton can be over the top – only automate something when you need it
- It’s a subtle art though – you don’t want to end up with tons of tech debt
- You can spend a bunch of time working out the concept without having the capability.
- Could have a simultaneous technical alpha – looking at cross-functional requirements etc
- Try a walking skeleton of the architecture – a “scale model”
14) As a tech lead, what things are scaring you most about this project?
- Do a futurespective graph with time on the x axis and clouds of uncertainty. If the cloud is really close and has a lot of lightning coming out of it… pay attention to it!
- This is partly about risk management
* Whisky idea inspired by JK Werner.