See the table of contents for my other blog posts from the conference

• How plan long tern architecture when under constant change
• if on unicycle, focus on not falling. We are on the unicycle
• evolutionary architecture is guided change
• have to agree on what consistutes good. Not all systems need same level of security reliability, etc

Fitness function

• how we define good.
• Needs to be clear so no disagreement on whether the system meets. So cant just say “maintainability”
• examples: manual vs automated, temporal, triggered vs continuous, static vs dynamic
• think of us a test
• chaos monkey is like a test. You know configured correctly

Principles

• Make decisions at last responsible moment. Know the nost then
• evolvability needs to be a first class citizen
• how communicate across non functional requirements
• minimize logic to minimize change. Dont do unnecessary work
• testability
• Conway’s law. The communication structure of your system will mimic that of organization. Communication silos in an org result in broken ntegration

Techniques

• Continuous Delivery
• Database refactoring – can’t migrate a system if you are being held hostage by the data
• orchestration – the orchestra follows the conductor.
• Consumer driven contracts. – dont have to think about until test breaks

Kinds of monoloiths

• Ball of mud
• layered monolyth. Can’t change without coordinating across all layers. reduce costs by standarizing everything. Slows things down. IT is an enabler and not just a cost center
• modular monolyth
• micro kernel architecture is only adaptable in ways you predicated. Also have to write the adapters so have more code/bugs

My take

Good talk. It was interesting and applies to almost everyone. I particularly liked the principles. I would have liked to see the slides after it got stuck. The talk was clear. But it is a long day and would have been easier to follow by visually seeing the points on principles and techniques. Im glad she acknowledged the slides not working at leaat

See the table of contents for my other blog posts from the conference

@brianverm

Lambda

• Function definition not bound to an identifier
• arguments being passed to higher order functions or used to construct higher order functions
• In Java, like an anonymous inner function. Only exists at runtime

Lambda length

• Want lambdas to be one line
• If more than one line, probably have a separation of concerns problem
• If more than one line, put it in a method with a reasonable name and use a method reference

Should you return a stream

• A stream is not a data structure
• Can’t reuse
• Don’t store in a variable. Invites people to use it twice and fail.
• No way to programmatically determine if a stream has been used
• Useful to return streams: for private intermediate function, when new stream created every time or when result is very large or infinite
• If not sure, return a collection instead of a stream

Mutable objects

• Functional programming avoids changing state and mutable data
• Less moving parts on immutable operations
• “A stream cannot mutate” (well; isn’t supposed to)
• Better to make a copy of the object with the desired state rather than changing the original

For each

• It’s just a for loop
• It can mutate state, have side effects, etc

Order of operations in stream

• Logic
• Infinite streams – can keep generating values and won’t stop if don’t haven’t limit or something that makes finite

Infinite stream

• Be careful
• Only use if needed
• Fork/join is in an infinite pool. Will get slower and not faster with infinite data

Create higher order functions

• Avoid duplicate code by changing “middle” of code.

Optionals

• Java’s implementation fo the Maybe Monad
• Encapsulation to handle possible null
• Forces user to unpack/handle before using it.
• Don’t set/return null for an optional. Use Optional.empty() instead
• Use isPresent/get as a last resort. The other Optional methods are better
• Make sure orElse() doesn’t have any side effects and only to assign a default value. Otherwise use orElseGet()

Checked exceptions and lambdas

• Doesn’t compile
• If want to do at point where exception happens, wrap in runtime exception and continue. Problematic because need to do it every time.
• Alternatively, can create own functional interface that declares a checked exception and a helper method that calls the functional interface and catches the exception. This is even more ugly because abstracted further away. It’s like a wrapper function.
• [he didn’t mention changing to an unchecked exception or a static utility to just wrap the method].
• If want to ignore exception and process rest of stream, can use Either (a pair object), can keep track of whether there is an exception. Can implement Either yourself or use Fibers library

My take

Good content. The functional programming slide “highlighted” key words with worse contrast, but not a big deals. While this wasn’t new to me, it is good review. And if gives me arguments for my teammates when they use these anti-patterns. I like that he used some live coding. The stuff at the end was new (Either), but I felt like we were running out of time.

See the table of contents for my other blog posts from the conference

@ValarieRegas

Speaker

• The speaker has one year experience in development
• She was a stay at home mom after having an unrelated underground
• Was a junior at 35 years old
• [This is good because she has more life experience than your typical entry level employee which provides a different perspective than the one you typically hear]

“People are a resource” [grumble; I wish we shouldn’t call people resources. She meant it in a positive way, but still]

Costs when someone leaves

• Recruiting costs
• No productivity while interviewing/discussing. Cummulative over interviews
• Onboarding costs [she then listed hardware; but that’s not new per person unless you customize everyone’s laptop and desk]
• Time spent learning codebase/process
• Learning to trust new person

Cyclic

• Senior developers need to teach junior developers to become senior developers.
• Can’t promote when people aren’t ready “behind you”
• As a junior dev, responsible for yourself
• The team needs to meet expectations and succeed together.

Tracking accomplishments

• Keep list of accomplishments for review time [I do this too]
• Include examples of what you encouraged/helped the junior to do

How mentoring helps you/the team

• Teaching others helps you understand it better.
• Refreshes memory of something you don’t do often.
• Get faster at doing job.
• Delegating tasks to the junior so less work [I disagree; there’s always work to be done. You can make the team accomplish more. And you may not have that task anymore, but you won’t have less work]
• Feel good/proud of the junior for accomplishing

How to mentor

• Talk to your supervisor. Need to free up some time. [my team has a 10% employee tax. Except for an intern’s first month, I don’t allocate more time above the employee tax. I do still talk to my supervisor, but it’s not about allocating time]
• Explain what expect. Team process and workflow.
• “A short time investment up front will save you so much time down the road”
• Tour the code base
• Give them a hard task so they feel a sense of accomplishment and gain confidence.
• Have a style guide/set conventions. Code, github comments, tickets.
• Don’t mock a junior [doesn’t this go without saying?]
• Set time limits so research isn’t open ended. Then they know when to ask for help.
• One on one’s important. Every 2-4 weeks. Discuss goals. The junior should come up with or help come up with goals. Provide feedback on whether reached.
• Success is getting to the point where you can’t answer junior’s questions off the top of your head.

Survey

• Did a survey in the South EastMost people had bad experience as juniors
• A lot of people didn’t have a mentor.
• 37% of those who had a mentor, felt like their mentor didn’t want to help and avoided helping them.

Q&A

• How deal with expectations that turnover is ok – do what want and tell leaders after the fact. Then propose changing more broadly.
• How avoid people becoming a time sink with questions? Average person should get it after 1-2 times if teaching they way the person needs to be taught
• What other resources besides mentoring? Pluralsight, linux academy. Study on Fridays instead of meetings.
• How do you manage resistance when someone doesn’t want to be mentored? How mentor experienced people? If a person doesn’t want to learn, maybe they should do something else. Junior people tend to be really enthusiastic and want to learn.
• How help overly ambitious junior focus on tasks? Limit by time. Some goals can be for current quarter, next quarter, two years, five years, etc. Makes the goals more achievable.
• What if overqualified for job? Give examples of what can do.
• What could a junior developer do to make it easier for mentor? Look at calendar and ask when not end to end meetings. Learn when good chance to ask. Send message “when you get a moment, this is not an emergency, <explain problem and what tried here>”
• What if learning style incompatible? Find a different mentor

My take

She articulated the topic well. The real world analogies to judo and marriage/kids were good. It was great hearing her perspective and using it to reflect. She’s a new speaker (there were a lot of paper notes.) But it didn’t affect the flow of the presentation. And I’m glad to see someone newer to speaking (on her career) at the conference. It inspires others to get up there. I also like that she did a survey to get more points of view. I also like that she explicitly encouraged/demanded Q&A. Good advice in there too.