DevNexus 2019 – Proper Care and Feeding of a Junior Developer – Valarie Regas

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



  • 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


  • 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.


  • 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.


  • 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.

DevNexus 2019 – Go Java Go! – Andres Almiray

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


Java is 23 years old. Go is 9 years old

To run

  • go run prog.go – compile to temp directory and run
  • go build pro.go – explicitly compile
  • ./prog


  • package name [no semicolons]
  • import “target”
  • fun main() {}
  • fmt.Println(“Hello World”)
  • fmt.Println(“one”, “two”)
  • if a == b [no parens]
  • func name(type int) int { return 0 }
  • fun name() (int, string) { return 0, “OK” } – can return multiple values
  • type Name struct { name int } – when need to create a type. DOn’t need a lot of them
  • s := MyStruct{value}
  • s := MyStruct{name: value}
  • fun (s MyStruct) function() {} – attaches function to a struct. Can then call on a MyStruct variable


  • uppercase symbol means public
  • lowercase symbol means private (to package)

Data structures

  • var strs = []string{“a”, “b”} or strings := []string {“a”, b”}
  • mapOfValues := make(map([string]int)) or mapOfValues := map[string]int {“a” : 1}
  • mapOfValues[“foo”] = 1
  • var array [4]int – ust be exactly 4 ints


  • Can create nested functions
  • No classes or methods
  • Constructors are automatic
  • Get compilation error for unused code
  • Only one keyword for loops. Use “for” and omit sections to make while loop
  • No exceptions
  • float64 data type

Features unique to Go

  • The interface{} type is roughly equivalent to java.lang.Object. “Just” need to ensure provide implementation of the method.
  • can use return type “error” and call errors.New to indicate an error. Can return nil if no error. Assign error to variable named _ to indicate to compiler that intentionally ignoring. [I don’t get how this is better; it seems like there would be error handling everywhere]
  • Type cloning: type foo int – treat foo as int. However, cannot pass foo when int expected
  • Type alias: type foo = int – treat foo as int, but can pass foo when int expected
  • gRPC – use instead of REST. Remote procedure call framework. gRPC works with many languages including Java and Go.
  • web assembly – can run go code on the browser. Can compile Go code into web assembly


  • Runs faster than Java with Java defaults. Not comparing to Graal for native code
  • When build code, runs faster than simply running it because interpreted


  • -run Go online
  • – automatically formats code according to go standards. Developers do not get to choose or argue.

My take

I learned a lot and it was easy to follow. I can feel my brain getting full.

Dev Nexus 2019 – Java Puzzlers NG S04 – JFrog

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

Baruch Sadogursky @jbaruch and Viktor Gamov @gamussa

#javapuzzlersng #devnexus


  • Java Puzzlers – 2001 at Oracle Open World. Did many years in a row
  • For later versions of Java
  • Slides with all answers at


  • Only a handful of people on Java 11.
  • Most people on Java 8
  • Unsurprisingly, hardly anyone on non-LTS versions

Note: they requested not posting the answers (even though they are online).


  • If you have an instance variable does This.this.this or this.this compile?

Fun facts that are not the answers

  • Can use non-English characters

How I did/observations

I got 33% (3/9) right. Well, slightly better than guessing randomly :).

  1. I was one of two people to get the first one right! It helps knowing it is a puzzler. I would have guessed compile otherwise!
  2. A lot of people including me got this right. It turns out a new an obscure bit of trivia that showed up in the question but wasn’t relevant to answer it. Fun!
  3. First one I got wrong. That was subtle!
  4. I got this wrong again. I knew the first trick, but not the second. Damn, the compiler is smart!
  5. Three wrong in a row. Again, I saw the first trick, but not the second.
  6. Fourth wrong in a row. Definitely a WTF moment for the answer! (These are great)
  7. Fifth wrong. “Good distribution of answers” – does that mean people voted randomly?
  8. Finally got one right after a while
  9. Ooh a Java 10 one! None of the tricks I could think of in this space are in the question. (Got it wrong of course)

My take

This was fun. They are great showman, have good rapport and had really obscure interesting puzzlers. I also like the showed docs for some of the obscure stuff.