Ellis Collado

I can't write code at night... Said no engineer ever. Why are companies so focused on having all engineers available during the same hours during the day? Hire contractors to do some of the work during off hours. What could possibly go wrong? They get work done and avoid needless meetings? If you can hire a contractor that has set up a specific technology 100s of times and they can get it done in a day, over asking one of your employees to try to hack it together over weeks, why wouldn't you? Let them do it in off hours!

7

3 Comments

I believe the DevOps Engineer role will vanish by 2026. • I am talking about the Role, not the principles. DevOps is here to stay. • Technical Debts are at an all-time high, leaving less space for hiring multiple folks for the entire DevOps & Reliability landscape. • In Big Tech like Google, and Amazon, devs are encouraged to take the entire ownership(dev to deployment) of the feature/product they are working on. Thus as compared to the size of the giants, you won’t see that many openings. • Most of the Startups & Mid-Scale companies have already scraped out most of their DevOps team. • Not to forget how Platform Engineering is simplifying the dev experience & reducing friction. Should you get discouraged? Absolutely No. Learn things, get hired and eventually change your route. It’s not new, in every 5-7 years the tech cycle changes and most people do change their tech stack. P.S. I don't sell courses, so this is an unbiased opinion.

710

52 Comments

SWE Industry: Never manipulate strings in Prod if it can be avoided, and if seen in a PR by a staff/principal engineer would immediately be rejected Job Market: Manipulate these strings in weird ways on this assessment so you can get this job... Wild, if you are interviewing software engineers, give them real world problems to solve, not some arbitrary random string manipulation that we would never do in production. You're likely missing out on a lot of talented people.

31

Unpopular opinion: It's not the software devs who need convincing. Selling devs on TBD, TDD, CI/CD, and ensemble programming, is a waste of time. We need instead to focus on continuous feedback. We need to sell it to the higher ups. To the people who call the shots. Because in the end, the aim of these tools and processes is to decrease the time it takes for us to collect valuable feedback from customers. Once the c-level people are sold on the merits of fast feedback, software devs will quickly learn how to write and deliver quality code.

6

4 Comments

DevOps is not a Job Title, it's a mindset/philosophy. This is how we will know if that debate has finally been won. The 390,000 DevOps Engineers on LinkedIn will change their job titles. Until that happens, sorry but it is a valid Job Title. (Even if I prefer SRE, Platform Engineer, Cloud Engineer, or Backend Developer.) #devops #sitereliabilityengineering #platformengineering #cloud

9

2 Comments

I saw this post earlier and got fascinated. As someone who maintained a calendar app for many years (https://lnkd.in/d9r4Va4M), I say Hillel Wayne is totally right. To say "always use UTC" is like saying "always use booleans." Sure, they're useful, ubiquitous, but you have to know what to do! Recurring events are especially tricky. Calendar apps usually solve it this way: 1. save the local time plus the time zone (for example, "2024-05-23T14:15 America/Chicago"); 2. convert this local time+tz to a point in the line of time (e.g. UTC or Unix timestamp); 3. convert this to your current location's time zone. Displaying these events require TWO time zones of interest: the event time zone and a display time zone. I'd recommend NOT storing the offset, though, as it causes issues with Daylight Saving Times, leap seconds, political changes etc. Instead, I'd save the time zone in IANA format and use the OS or a library wrapping the Olson database for conversion. (Technically, one could save the time in UTC or Epoch time, too. However, now they would need to convert this point in time to a local time, and then proceed with the steps below. We actually did it in the Liferay Calendar, because it was originally written to save Unix timestamps, and moving from it was never the highest priority. I'd rather not do it now, though, that just adds an extra step.) A great tool is Joda Time library or any of its derivatives, such as Noda time or the Java Time API. Their types force us to understand what we want to do. In such a confusing topic (as we can see by the other comments) it is a great tool even if you are not going to use the library in code. #timezone #date #time

9

2 Comments

Software engineers, it’s time to reality-check your salary dreams. I’m tired of hearing inflated salary expectations from developers who do not know what the market pays. Do you think you deserve 3x more? I’ve got financial data that says otherwise. Advice: a) Listen to your recruiter. We’ve done our homework. b) Be humble. Market value is what companies are willing to pay, not what you think you deserve. c) Adjust your expectations or watch your opportunities disappear. Trust me, we want to get you the best deal. But when your numbers exceed the CEO’s, it’s time for a severe reality check. Keep arguing with the people who hold the data and see how far that gets you in this competitive market. PS: The more you earn, the more we make, so believe me, it is in our best interest for you to have more than Elon Musk. But reality is what we can't bypass. PPS: Always stick to market value. If it's too low for you, we can add 20% on top to sound reasonable. If even that's too low for you, you are too low for us to waste our time further. #SalaryRealityCheck #RecruiterTruths #SoftwareEngineerSalaries #MarketValueMatters #RealTalkRecruitment

4

Five of the worst software engineers I ever worked with had this one common trait 👇👇👇 Disclosure: if you have this trait, you can work out of it. Over the last five years, I have worked with some tremendous engineers. But nothing leaves a lasting memory like someone you hope you will never have to work with again. I always have been a huge advocate of the right tool for the right job. With these five people, it was the tool they preferred for the job, whether it was right or not. - They were not willing to try something new. - They were not willing to explore other options. - There was no persuading them. 'Strong opinions loosely held' - never forget. We, as software engineers are problem solvers, not code monkeys. Since you are here, check out the link to the Developer Careers Academy in the comments, where you can network with like-minded engineers and build your career the right way.

60

14 Comments

It's NOT over for software engineers - if anything we're on the cusp on another market 📈 These new tools - Cursor, Sonnet, V0, Replit - they're not threats. They're catalysts. Here's what will happen: 1. Non-coders will build MVPs easily. 2. More MVPs means more potential startups. 3. Successful startups need engineers to scale. 4. Result: More engineering jobs, not fewer. It's counterintuitive. But progress often is. This shift will democratize startups. Anyone with an idea will be able to test it. The best ideas will get funding. Funded ideas WILL need real engineers. The tech industry won't shrink. It'll explode. New voices. New ideas. New problems for engineers to solve. Software engineering isn't dying. It's evolving.

46

3 Comments

Interesting conversation for those just beginning their careers, in engineering or beyond. Thanks for sharing Andy Greenwell!

3

1 Comment

Exactly! 👍 That’s why the position is called as “Engineer”. Programming languages, run environments, frameworks & libraries - that all are tools only. A good Software Engineer should learn and should know how the core works, the basis of what he is working on. Of course, experience in a given technology is very important, but the tools change too quickly to become addicted to. We shouldn’t treat the universality of software development process as a mistake.

2

I don't see the value in managers coding. Any time spent coding could've been spent handling duties of the manager role. If the reason for coding isn't based on capacity constraints, I don't understand what value that adds. An area where I do see great value could be added by a manager staying very technical is in architectural / system design discussions that require a broader view of the tech org.

42

5 Comments

Software Engineers: How many times have you crushed an interview only to hear, "We’ll circle back after a few more interviews…”? Frustrating… right? This Black Friday, I’m dropping a toolkit that changes the game and puts YOU in control: Become the first engineer hiring managers think of when they need to fill a role. Decode employment types (freelance, full-time, contracts) so you can get paid YOUR way. A strategy guide to make recruiters chase you, not the other way around. A layoff survival kit: because let’s be real, even engineers need a backup plan. PLUS: My $200k salary negotiation script that personally helped me earn $629,479 All of this is dropping for practically nothing this Black Friday (99% off). Want in? There’s a waitlist. First in line gets the biggest edge. I'm only making this available for 30 people because I'm literally losing money by giving it away at this price. DM “MASSIVE” if you’re curious. I’d love to share the details. – Tyler

1

1 Comment

What if you have a savant in your team? In my case, the savant is the initial founder, CEO and investor, now joining forces with co-founder who will be the new CEO. The savant is me. I strive in innovation, chaos, disruption and lightning-fast execution. I am also a business guy. Check out my LinkedIn profile to find out what I am up too. In short: LLM 2.0. We started raising funds and talking to potential clients, mostly large companies. My job as a savant is to protect my executives from deep science at all costs, steer them and let them execute. There is also something I call "execution genius" (or sales genius aka rainmaker) and I deeply respect it and love having them as partners. Just giving the perspective of a "savant" here.

29

2 Comments

I always begin projects by creating a diagram. I find Visio to be the best tool for this.

10

3 Comments

In Requiem for Adult Management: Even unicorns have only one horn I recently saw a job post for a senior manager that had: * Extensive hands-on skill writing C++ * Low-latency system expertise * Cloud architecture (particularly many years with AWS) * Low-code platform expertise * Many years managing teams To borrow from literature, one is reminded of this famous line from Jane Austen’s Pride and Prejudice: “I am no longer surprised at you knowing only *six* accomplished women, Mr. Darcy. I rather wonder at your knowing *any*.” While it sometimes possible to find a CTO who is also a first-rate hands-on developer who embodies every skill, it’s rarer than a two-horned unicorn. We often will not find what we need to make our organization run. Or worse, hire something that does everything we ask but does it badly. It usually a fool’s errand to look for one individual who can do everything, that doesn’t mean we have to have a separate person for each and every skill. When designing your team, figure out what your budget it and what skills are core to your product. Then see what combinations there reasonably are. For something core to your product, hire the best you can. Then fill in the gaps with a good full-stack developer and/or a good generalist. I was at a seminar recently and the speaker brought home the point that a full-stack developer is a very different skillset from AI-developer. Yet, almost every company that requires AI developers, also needs full-stack engineers to deliver the product. These are almost always separate humans and it’s incredibly rare to find someone who can do both WELL. Most companies that try, usually don’t have good outcomes. A CTO also needs some skills outside of core development. The role also requires expertise in general business, hiring, release management, product design and a good sense of risk management. The role is as much about choreographing the team as is it about building the product. In the example at the top of this post, it might make sense to break the role into a director who has full-stack experience, a track record managing, and maybe some low-code experience. It’s going to be a lot easier to find an engineer who is an expert at C++ with low-latency knowledge than one who ALSO is a skilled people manager with budgeting experience and substantial DevOps knowledge. It’s possible to find one person, but it’s going to be an expensive search with a VERY expensive hire with a good chance of failure. Don’t look for a two-horned unicorn, especially when there are a herd of racehorses just one field over.

19

2 Comments

Ever notice how job postings for junior developers have practically disappeared? It's not just you. The traditional dev team structure is crumbling, and here's why: 5 years ago, dev teams were a pyramid: - Lower 1/3 of the pyramid were junior devs - middle 1/3 of the pyramid were mid-level - highest 1/3 were senior devs Today? Companies are only hiring senior developers. But here's the problem: How do you become a senior dev if you can't get hired as a junior? The bridge is gone. New CS grads are stuck on one side of the river with massive debt, and all the jobs are on the other side requiring "senior experience." This isn't just bad for junior devs. It's devastating for companies. Because while you're fighting over the small pool of senior developers, you're missing the bigger shift: The way we build software is changing dramatically. AI is handling the routine stuff. What we really need isn't just more developers - it's better architectural thinking. #SoftwareDevelopment #TechLeadership #Engineering #FutureOfWork

771

200 Comments

Join me for an interesting session on #devex and how to think about organizational and engineering metrics.

15

You see an awful lot of LinkedIn posts these days about which languages are paving the way and taking over. But don't worry, Java isn't going anywhere. And here's why. There are many benefits to using Java when developing software, here are just a few: 🚚 High-load solutions 🤝🏼 A huge community 💻 Extensive applications with examples, libraries & ready-made solutions 👨🏼‍💻 Use in conjunction with Spring 💰 Financial technologies 💹 Reliability, stability and scalability ➡ Transition to Kotlin If you're interested in speaking to a Java specialist and seeing how I can improve the growth of your Java team, give me and shout and we can talk Java over a cup of Java! ☕😉 I'll leave the link to the full article in the comments if you're interested in reading further. #Java #SoftwareDevelopment #ProgrammingLanguages #Hiring

17

4 Comments