<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:dc="http://purl.org/dc/elements/1.1/">
  <channel>
    <title>DEV Community: Laurent Dumas</title>
    <description>The latest articles on DEV Community by Laurent Dumas (@laurentld79).</description>
    <link>https://dev.to/laurentld79</link>
    <image>
      <url>https://media2.dev.to/dynamic/image/width=90,height=90,fit=cover,gravity=auto,format=auto/https:%2F%2Fdev-to-uploads.s3.amazonaws.com%2Fuploads%2Fuser%2Fprofile_image%2F713472%2F6be04d91-ae3b-4e3b-b208-d7c05af27c58.jpg</url>
      <title>DEV Community: Laurent Dumas</title>
      <link>https://dev.to/laurentld79</link>
    </image>
    <atom:link rel="self" type="application/rss+xml" href="https://dev.to/feed/laurentld79"/>
    <language>en</language>
    <item>
      <title>Lead: This code is shit. Unpopular opinion: it's not.</title>
      <dc:creator>Laurent Dumas</dc:creator>
      <pubDate>Sat, 23 Oct 2021 07:24:31 +0000</pubDate>
      <link>https://dev.to/laurentld79/lead-this-code-is-shit-unpopular-opinion-its-not-1keo</link>
      <guid>https://dev.to/laurentld79/lead-this-code-is-shit-unpopular-opinion-its-not-1keo</guid>
      <description>&lt;h2&gt;
  
  
  Really.
&lt;/h2&gt;

&lt;p&gt;Have you said this before? Don't talk like that to a developer: in a code review or, pair programming, or help resolve a bug, etc.&lt;br&gt;
Don't get me wrong, I know many people are gonna say: "yeah but look at it! I mean, this is too much".&lt;br&gt;
I'm saying that because, saying code is shit is not helping. We developers tends to appropriate our code. We should not. It's your company's code. Even you are an independent, you have to depersonalize it. I think the best way to modify code is to consider it is not our own. The more you think like that, the more you will be open minded to find solutions.&lt;/p&gt;

&lt;h2&gt;
  
  
  Saying it's shit, doesn't do good.
&lt;/h2&gt;

&lt;p&gt;You know, be kind with others. As a lead, don't forget that what you're saying has an impact on people mindset. If you're saying a code is shit, you are maybe hurting someone. Saying shit don't help the person who wrote it. Saying that we can write in other way helps because it's faster, more open, etc.&lt;/p&gt;

&lt;h2&gt;
  
  
  Empathy
&lt;/h2&gt;

&lt;p&gt;If you're saying "your code", "the code is shit", you're just making yourself and people have a bad day. The developer may asking himself a lot of questions, feel bad, etc. And for you, because you don't want to do that all day long, it's put you on a bad mindset - and it's exhausting.&lt;/p&gt;

&lt;p&gt;And remember, as a lead you're here to help. Ask yourself that question: what do you want in your day? Helping the team, the project or judging things?&lt;br&gt;
So please, help yourself and others. Be kind ;-)&lt;/p&gt;

</description>
      <category>leadership</category>
      <category>codequality</category>
      <category>codereview</category>
      <category>discuss</category>
    </item>
    <item>
      <title>Best practice in SpringBatch</title>
      <dc:creator>Laurent Dumas</dc:creator>
      <pubDate>Fri, 08 Oct 2021 13:17:55 +0000</pubDate>
      <link>https://dev.to/laurentld79/best-practice-in-springbatch-2b2m</link>
      <guid>https://dev.to/laurentld79/best-practice-in-springbatch-2b2m</guid>
      <description>&lt;p&gt;Hi there,&lt;/p&gt;

&lt;p&gt;I'm looking for best practice in SpringBatch like: things which are mandatory, itemReader/writer declare in the same class as job, or in a separate one..&lt;br&gt;
Is there any resource on the subject? I think i may try to write some of these; I discover the subject so I need it, are people would be interested?&lt;/p&gt;

&lt;p&gt;It seems that there's not much of it online, i'm suprised.&lt;/p&gt;

&lt;p&gt;Edit: After reading here and there and trying myself on a sample project. I would start with these:&lt;/p&gt;

&lt;ul&gt;
&lt;li&gt;Just One Job in your batch&lt;/li&gt;
&lt;li&gt;Log jobParameters values, startTime via (JobLoggerListener)&lt;/li&gt;
&lt;li&gt;Log at the end of Job (JobLoggerListener): endTime, Status of Job, ExitStatus.exitCode, and description (maybe the returnCode for the system).&lt;/li&gt;
&lt;li&gt;Implements a ChunkListener to see in your log the progressing of your treatment.&lt;/li&gt;
&lt;li&gt;Organize your listeners in differents package so you can specify appender log for example just jobListener without log all the other details. So in Production, you have a nice log with just minimum information.&lt;/li&gt;
&lt;li&gt;Implements an ExitCodeGenerator to return to your system a meaning code for your ops team.&lt;/li&gt;
&lt;li&gt;Don't use Hibernate if not necessary, prefer JdbcTemplate.&lt;/li&gt;
&lt;li&gt;Use a HSQLDB database for unit testing.&lt;/li&gt;
&lt;/ul&gt;

&lt;p&gt;For books, I read the "The Definitive Guide to Spring Batch" from Michael Minella which is great to learn the framework.&lt;/p&gt;

</description>
      <category>springbatch</category>
      <category>springboot</category>
      <category>batchprocessing</category>
    </item>
    <item>
      <title>How i became a Lead-developer</title>
      <dc:creator>Laurent Dumas</dc:creator>
      <pubDate>Wed, 06 Oct 2021 16:54:16 +0000</pubDate>
      <link>https://dev.to/laurentld79/how-i-became-a-lead-developer-16hl</link>
      <guid>https://dev.to/laurentld79/how-i-became-a-lead-developer-16hl</guid>
      <description>&lt;p&gt;I would like to talk about my experience to become a Lead-developer. In fact, I didn't see the thing coming. I went through many experiences and projects, and project after project, in a slowly way, i came to say my thoughts and tell people advice to handle situations. One day, project manager take me 'officially' on top of the team, and I realize it. The only problem, at the time, I didn't put a word on this role, so i kind just 'did' what i can about it.&lt;br&gt;
At the time, I would have liked someone to give me some advice, because my first experience i made mistakes, and I wasn't conscious at the time that role could have influence on people. Since 3 years, someone else has the same role, and it's really helpful to daily discuss.&lt;/p&gt;

&lt;p&gt;What about you? Did someone give you some advice? Or it was just a natural and logical thing to become a lead-dev?&lt;/p&gt;

</description>
      <category>leadership</category>
      <category>career</category>
      <category>discuss</category>
    </item>
    <item>
      <title>TechLead or DevLead ?</title>
      <dc:creator>Laurent Dumas</dc:creator>
      <pubDate>Sun, 26 Sep 2021 10:25:50 +0000</pubDate>
      <link>https://dev.to/laurentld79/techlead-or-devlead-369c</link>
      <guid>https://dev.to/laurentld79/techlead-or-devlead-369c</guid>
      <description>&lt;p&gt;Hi,&lt;/p&gt;

&lt;p&gt;Sometimes i read post about techlead but often oriented to the technical stuff, best practice etc. I think that Leading role can be separate in 2, the tech for one et and well "dev" for the other. In fact, i think the other is more about soft skill. Because being a great developer tech-wise doesn't not necessarily means that you can teach, give some advice with the right word.&lt;br&gt;
I think that Leading demands skill like Patience, Empathy, because you need to deal with different personnalities, and it's not always easy.&lt;/p&gt;

&lt;p&gt;What do you think? Do you make that difference, or see that Leading is like 2 jobs in one ?&lt;/p&gt;

</description>
      <category>leadership</category>
      <category>career</category>
      <category>discuss</category>
      <category>softskill</category>
    </item>
  </channel>
</rss>
