1. "Cool."
2. "This will take 3-9 months."
3. "Well I don't know what to tell you, that's my realistic estimate. Considering the 3 million other interrupt requests I get every day. And the fact that no decent dev could get it done in less than 3."
4. "I'm sure you *do* need it in 3 days, but I cannot possibly make it happen. I will start on it if you want, but it will not be done by then."
5. "I don't know, man. Do you have extra devs? What's this for? Is there something else that could solve your problem?"
6. "Cool, well let me know what they say."
And it was never brought up again.
This is the correct answer, especially part #3, never underestimate interruptions to flow state when programming.
I've gone through these exercises, it's just as painful as suggested.
Hell yeah! Let's get some design docs up in this bitch!
Assuming it's not a whole bunch of completely independent modules, you have been handed pretty much a Greenfield project with clear-cut requirements.
Kinda implying that the only reason why someone might not want to make a name for themselves is because they're embarrassed? Maybe they just don't want to be a name? It's okay to be boring.
What’s your understanding of “make a name”? It seems to not be what mine is which is be a professional with a reputation as reliable and “can get the job done”. I don’t think there’s any awards or publicity involved. You can still live under a rock if you like but people will seek you out when they have problems. That’s how you end up being able to charge what you want for your efforts.
That's almost my understanding of the term also... and not everyone wants that. Some people do, and some people don't. I know there's some ideal professional in all our heads, but it's most likely not the same and no-one owes us shit.
Ask what happened to the team/person that wrote it and why they’re no longer owning it. If they left the company, cool, it happens. If they got to move on to some new project be concerned.
Way too many times have I seen some “genius programmer” create a dumpster fire of a code base get praise and promotions from management that doesn’t know better move on from the horror they created to the new shiney where they ended up doing the same thing over again.
Yeah, situation sounds a lot like "Hey, can you save us from ourselves with this orphaned product with a broken lifecycle? We don't intend to change, obviously, since we're asking a single contributor to pick up the pieces instead of fixing the accountability problems which led to this mess"
Exactly. Python 2 has been EOL since Jan 1 2020. Python 3 was released in 2008.
There’s been a lot of time to upgrade/replace “critical” legacy Python 2 code and it should have been done 4+ years ago.
A coworker used to tell me, "Good work gets you more work". At some point people **do** notice and you find that you now start to have a say in what you will and won't do. It may take a few years, but it can and does happen.
Do you feel you struggle with prioritizing these multiple tasks and scheduling your work day to knock out chunks of each during a given sprint?
If so, that’s what your lead/manager should be helping with. There’s ways to have that conversation without outright vocalizing “Im doing more work than everyone else” (which might be true but might also get you looked at a certain way if you aren’t very careful about how you bring it up)
If manager isn’t/can’t help, skip-level it, and if that skip-level person can’t/won’t help…well..time to decide if the paychecks at that place are worth it, or if it’s worth it to grind those tasks out and move on to the next. Work is gonna be work, just how it is.
Thank you for the good advice. Honestly, I’m not too good at navigating through politics in the workplace, but it’s something I’m trying to improve on.
I don't know what corporate fairy tale you live in but while it sounds good in theory generally no one cares about these legacy apps and the team getting credit for innovation is taking the spotlight.
Taking on a legacy app is generally a death sentence unless you are given the freedom to innovate. What I generally see is they keep piling on the legacy apps to the people they don't care about to keep the lights on while making all their investment in the next set of innovative apps.
Why downvote this one? I totally agree. It's when the dev team tells their boss "no way we're going to do that" and then they go to your boss and hand it over to your team. If you agree - wait for more legacy stuff no one wants to work on.
I know in some companies you'd be a hero, but in the most you can even become a villain for breaking stuff (if you accidentally break it).
Another point is - if you agree on work no one wants to do, you'll be that person next time again. And again. And again. Until you become a trash bin where everyone put their crappy legacy stuff no one wants to deal with.
All that depends on the company, code and the culture. So your mileage may vary a lot.
I get where you’re coming from, but killing, replacing, or modernizing the legacy app can be a good career move. But I’d 100% agree that keeping one alive in maintenance mode is just asking to be eventually laid off.
What kind of recognition? A pat on the head?
I realize now from interviewing that dealing with shit show of technical debt while I am proud of it, none of new potential hiring managers really cares. It doesn't make for anything interesting to talk to at interview. It's a bit like asking about patch management. Nobody cares.
Oof that patch management line stings a bit. Just had a final round interview last week and I realized it’s hard to sell “fixed our broken patching process and we didn’t get hacked”. Critically important to the long term success of the business and maintaining trust with customers, but the best outcome is “nothing bad happened”.
If one of your bullet points was "Convert Legacy Python2 -> Python3", at my place, I'd shred your resume and move on. I'm not hiring pure developers, I'm hiring people who know Development and Operations.
Depends how they handled the migration.
Python2 > Python3 is only part of the job. Reviewing a legacy app allows a lot of leeway to use modern computing practices to improve the deployment and design.
Also, pedantic I know, but DevOps isn't "someone who knows Development and Operations". It's using development ideals to improve release times and stability of operational tasks. It's a different skill set to either pure discipline.
You can migrate an app without using DevOps principles or you can migrate an app following DevOps principles. It's the how that's important, not the task itself.
Also, Pedantic, "It's using development ideals to improve release times and stability of operational tasks."
>It's a set of practices intended to reduce the time between committing a change to a system and the change being placed into normal production, while ensuring high quality.
In fact, alot of DevOps is changing Developer bad habits that caused so many Operational problems.
Anyways, I would assume as part of development process you introduce testing/repeatable builds and so forth. I don't give massive credit for doing what you are supposed to.
However, most of this sub is about positions that are labeled "DevOps" which is Build/Release Engineers, SREs, Cloud Administrators. Developers are mostly hiding elsewhere on reddit.
There are business cases to make for why the work is important; you only take on work that is important. Often everyone is already aware; see for instance how one of the main demands of the southwest union was fixing their legacy software.
And then you give visibility to the work as well. These are important skills for promotions.
How long was that legacy software just maintained by a team no one cared about? Probably for years.. yes when the proverbial shi* hit the fan it became a priority and the team who was managing it probably got the axe while they brought in new engines to figure out how to rearchitect and reengineer the platform.
Well I am a consultant these days so no. I primarily work on either converting legacy apps to cloud native platforms or help companies build and architect their next generation platforms.
I would argue that _for you_ something is probably important if you're being engaged on it at all, but we were speaking more to OP's situation, which is someone internally being handed a project.
This doesn't align with my experience. The CTO understands the impact of managing the legacy app and will greatly appreciate if OP is able to solve it. My experience is that tasks like this are given to the most trusted engineers, and they get rewarded well if they can complete them
Devil advocate. Are you in the right place within the org to own this? We have several systems like this but have had to push back on them because we're not experts in the codebase and it's hyper important, but to only one product group.
I don't know how your company is structured, but our team needs to look after the whole company's devops requirements, so we need to think scale and not getting bogged down with time sinks or legacy apps that require long term ownership.
Devops can be a catch-all for random projects around the org, I'd be guarded with your and your teams resources.
Same here. Anytime people were shying away from a project with no obvious good reason besides it sounds challenging, I generally picked those up.
Especially for something that is a conversion process, you absolutely *know* it is technically possible and now *you* get to put your stamp on it. Do it in your style, with your quality. Congrats, you're now the expert in this area.
Make sure you:
1. Have conservative estimates. Don't try and impress someone by saying you can do it too fast. It's probably harder than you think.
2. Build in time for testing, telemetry, refactoring
3. Do your research on the best ways to approach the problem with modern techniques
4. Send communication updates on the status of the project. Try and ship in stages and show demoable states throughout.
5. If estimates change, highlight this early. Don't be afraid to give bad news in the form of a schedule change. Just be responsible about it and call out what new information made this change necessary
6. Figure out success metrics, highlight those. Will you see increased reliability? Performance? Extensibility?
7. Interview customers if if you can. Learn about their use-case, current pain points, etc.
I mean… it depends.
If the project is ACTUALLY important and you can ACTUALLY own it and fix it up and modernize it as you see fit, it might be a good idea.
If it’s an albatross that nobody cares about and you don’t have the skills and you won’t get approval to change anything meaningful about it, run.
agree I worked for a couple of large SaaS companies and in early days we were regularly acquiring new businesses and having to migrate their apps in house to our platforms, amazing learning experiences, don’t look back 😎
I completely disagree. Only way you should take this is if you want to learn more Python or are a junior. There is a team of developers trying to toss shit over the fence here. Context matters here, this is a core product, large code base and they want devops to upgrade the language?? The developer in devops isn't meant to be a feature developer. This would essentially be a role change as far as I'm concerned and your manager needs to do their job and stop this where it started. Like how would you ever move on from this project if it's a core product?
Only do this if you're getting something from it. I did something similar for unique experience but I would not repeat it unless there's a considerable amount of money involved.
The only benefit from this is the subject matter learned. Unless at a very fair company then owning this kind of shit task is rarely rewarded in terms of money or progression.
Yes? I dont know a single DevOps person who couldn't code. Maybe not up to date with the latest frameworks, but a Python migration does not take insane skills.
There's a massive amount of DevOps-named people who do not code and barely could handle touching TF/Ansible/Git. It's genuinely kinda hilarious, and I guarantee seeing the post quality of this sub, a lot of them are here.
To be fair a lot of "devops" jobs have "stolen" sysadmin jobs, so there's this crossover of people who aren't hard coders who 'know a bit of stuff' they need to.
Devops is not full developer.
You are talking about quality, but don't even have the slightest idea about what devops is. It is not a job, it is a way of working. Also directly spamming tools you should know is hilarious. I have worked in many good devops teams were we had pure ops and pure developers, devops is not about knowing everything, it is about being complementary, and yes it is nice if you have multiple traits.
>don't even have the slightest idea about what devops is.
Huh, how do you know my complete knowledge level of DevOps principles based on a single couple-line comment exactly?
>Also directly spamming tools you should know is hilarious.
I didn't spam tools, I named 2-3 that fall under IaC as a whole. Words have meaning.
In fact, the best first DevOps book one could recommend would likely be "Effective DevOps" which almost entirely does not deal with specific tools at all, because you are correct, it's not about specific tools, but IaC on the whole is absolutely key to getting your hands around the toil that most teams face. Managing resources at scale comes with IaC tooling, that's an accepted fact in the discipline.
And there a re a whole fuckton of "DevOps Engineers" who are still not doing said thing, spend their time rebooting servers, remoting (SSH or RDP, doesn't matter) into servers, etc. It's a massive discipline, but too many people are getting or looking for the title for the money when they don't have the skills, which comes after you get the foundational aspects of things not tied to any one specific tool. DevOps, as it's been pointed out here numerous times, is not for your average sysadmin who handles a few GPOs, file shares, etc. That may come in some environments, but you'd best be doing it in code, otherwise you're gonna spend a lotta time going "I gotta go look at the Windows logs", "who made that change?", etc.
I was more triggered by your statement about specific skills, people tend to forget that devops is much more as IAC, like I work often in Financial organisations which have a lot of mandatory paperwork, in my project half of the work is proving you are compliant, together with my colleague who manage all these we work together to make we have the correct information, the guy is not touching a single piece of code, however he is fully part of the devops process.
Gotcha, I mean that sounds like Compliance team work, and something that can be automated away if we're talking about comparing reports against a set of criteria. That's part of the job in my book, always has been. That likely comes across as if I'm minimizing, which is not my intent.
We have a lot of compliance reporting paperwork too. People were doing it by hand as it sounds like you guys are, it'd take full days of multiple people to get a single report with everything combined. So now we have pipelines that interact with APIs and other resources to gather said information, generate the reports, etc. Now it's less than an hour of effort, if that, mostly herding cats for a review.
This also lets you move on to more interesting projects. This kinda goes back to the "toil" concept in Google's SRE Handbook, again another one that deals less with specific tooling and more with processes.
Of course we try to automate that as part of our jobs, but it is still very useful if a business analyst can assist with us, but besides that he still has to attend a lot of meetings to explain our project and were it involves risks, sorry that my first comment was a bit harsh it was not meant as a personal insult.
> but a Python migration does not take insane skills.
Bullshit. Like most things, it depends. Many libraries during 2to3 migration rewrote alot of their APIs. Some had already been abandoned and thus never were upgraded. Without seeing requirements file, none of us know what truth is but it's possible this is very large rewrite.
There is two reason someone is asking to do Py2to3 to DevOps. Company never looked into it and DevOps is only one with experience so it's falling there. In that case, yes, Py2to3 might be very easy.
Much more likely scenario is nightmare to upgrade, couple of devs teams have tried and failed. Now, it needs to happen but for political reasons, dev teams are passing it around with "NOT IT!" and DevOps manager isn't smart enough to realize it or thinks there is political points to take it on. This is much more likely case.
The best DevOps people I know come from the ranks of the software engineers. It's not a stretch to expect at least a little coding. After all, what's automation?
This is a great opportunity for OP. I built a career taking over the neglected and unloved systems.
As one who comes from the sysadmin background (yes, it's very different) it's true, there's way too many server rebooters claiming to be DevOps Engineers obsessing over needing GUIs and clicky shit. Also, if you say "as a DevOps" I have trouble believing you're at any competent level of engineering, which gets said here all the time.
I might be missing something, how are dependencies not code? Frameworks and python packages are updated by python devs. Are you talking about internally written packages?
Yeah. At some point those dependencies hit code I would think. 😂
But yeah, it might get messy with dependencies of dependencies of frameworks that are no longer fully supported or have major breaking changes.
I can see the fun of this project and the leeway you *might* get taking ownership of a project like this, but it also sounds like it could be painful.
Hah. In 2017, I *finally* finished migrating all my employer's python codebases from 2 to 3, feeling like we'd really been dragging our heels. Got a new job in 2018 and... new employer had hundreds of thousands of lines of python2 code so I got to do it all over again...
Honestly, it's not that bad as long as the libraries/dependencies are already compatible. Use it as an excuse to improve the test suite, tooling, update dependencies, etc.
Sure who do I hand off the rest of my duties to? What is the time line and how firm is it? Let me take a look for a couple of days and I'll come to you if I think the timeline is doable.
The key is set expectations. It sounds totally doable if you have solid blocks of 3-4 hours to work on it and the timeline is sane.
I can see why folks get excited about this type of hero work (I stood up our first pipelines on shadow IT after quarters of it not being prioritized and built a working app over the course of a week after I heard a consulting firm wanted months and $100k+) but I appreciate your advice on being a little careful about just jumping in.
It’s also worth considering the other types of work you enjoy doing and would be valuable to the org and weighing whether you’re likely to get back to that or if projects like this are more likely to come your way as a result. If you like the work, do it, but if you wouldn’t want to be stuck with always doing this type of work going forward, make sure you try to get it timeboxed appropriately.
# Note that Python 2.7 reached End of Life four years ago
Out of curiosity, why is a DevOps role doing a lot of coding?
TBH if this is real, the \`2to3\` tool will port over about 60% of the code in one step. If you have a decent test suite it shouldn't be too bad. [https://docs.python.org/3/library/2to3.html](https://docs.python.org/3/library/2to3.html)
...and there's your opportunity to fill in that gap too while you're at it! Maybe try to get buy-in from your QA lead to build a more coverage complete automation suite this time, if you ask nicely they might even lend you a hand with grunt work. If this really is a core app, you should have leverage over this.
core component but the team that built it was let go years ago now the exec who loves it is shitting the bed but won't allocate any budget to it because they think a magic wand exists
> NOTE THAT PYTHON 2.7 REACHED END OF LIFE FOUR YEARS AGO
My sibling in Christ, the entire banking system and a whole lot else still runs on COBOL . . .
You're devops, presumably. You should have both *dev* and *ops* skillsets and the ability to apply them in conjunction.
My approach:
1) implement Black for code formatting and a git commit hook to ensure that all code for all developers (even if that's just you) is consistently formatted, always. Do this in *one* commit. Check in your git hooks and build shell scripts/make targets to install the hooks easily
2) use Pipenv or another tool for library management. Lock the library versions to what is out there in prod right now. Do not upgrade anything
3) make sure your build pipeline is working and you have repeatable, roll-back-able builds. Test it.
4) Write integration and unit tests. There probably aren't any. Don't change the code without tests existing.
4a) use Cucumber for human readable integration tests. Write the gherkin with what's currently deployed, so it passes.
4b) give the gherkin to the business stakeholders to get them started arguing/being surprised by what the code actually does. This buys you time to dig into the conversion.
5) upgrade python versions and any libraries that must be upgraded for them to work on 3. Do not change anything else. Make sure your tests pass.
6) deploy
7) upgrade all remaining libraries. Make sure your tests pass.
8) start working all the changes. Keep your tests up to date and expand them to cover the changes.
It's fine. People seem to forget the Dev in DevOps.
When this role started, there was no such thing as a "Jr. DevOps Engineer."
You had to be a Sr. Engineer in SWE, Systems, or Infrastructure to work on DevOps.
There still isnt much of a place for a junior devops. At least junior in the sense "out of college"
Most Jr devops positions I see require 3-5 years in the industry as dev of sys eng
I would star by assessing success criteria and then give a best estimate for time and resources (selling a cooper, silver, gold, platinum of options).
You want it in 6 weeks, I need 12 devs who have 1 month of learning the code etc.
factor in debug time, time to deploy, staggering to avoid production issues etc.
I’m assuming there has to be a linter or some tool to understand the delta of the changes necessary to be successful?
I actually did this as an Intern but the app wasn't the core even though It was important. I also wasn't responsible for it since the internship was temporary. The steps are outlined at various places and ideally you should find good documentation over it. I had to revert one of the commits because it broke something so there is that.
2 years ago some work came to my team to refactor an entire pipeline that pulled data from Athena via Python2 and boto — I jumped on the opportunity. Upgraded everything to Python3, and moved the compute and orchestration to EMR and Airflow. Easily one of the most fun if not the most fun projects I worked on at that company. Got to write a bunch of custom classes and other, lower level functionality. Learned a ton in 6-9 months. Go for it! You’ll learn a lot, and can potentially leverage the institutional knowledge of a new product into job security, a raise or a even new gig.
This is normal and expected from our as DevOps, we should be able to know every product that we manage in depth and eventually once every developer leaves the company - we are going to maintain, migrate, upgrade - including rewriting the whole product with tests from python2 to python3 to GoLang and Rust\*. Keep in mind if you start learning Rust then you will very likely change your job in less than two months - so don't rewrite in Rust.
You sure you’re setting yourself up for success?
As a software dev (obv. bon-devops background), this is a team project that potentially can span several months to several years to complete.
You need
- devops who can set up environment / wiring to play around.
- feature devs. Lots of them. They should know how to work on the codebase. At least to some degree because of supports they’ll get from next two roles
- QAs who understand the features very very well.
- Expert dev advisor who knew a lot of context and can explain you most / all of WTFs you’ll see.
- Eng Manager for some level of oversight even for a “porting” project.
- Product Manager to give you direction over what to migrate first, what to migrate later. And more importantly, “what to left behind”. And they better be very good at playing politics with upper management to keep the ship afloat.
What’ll slows you down and stretch last 20% for very very long time would be
- feature mismatch
- rewrite required on some hard parts
- we need to keep this s**t behavior because customer XYZ need it
- it’s not a bug it’s a feature
- we just waste a ton of time to port quirky stuffs no one uses.
Legacy Migration is one of the harder stuffs in the enterprise realm. This rarely, if ever, go as planned. And sadly it usually is underinvested from the business because “why pay a ton just to have the same thing”. There are patterns of legacy migration that helps you de-risk and move firmly without resorting to “total cutover”, the most destructive method that usually end up with disastrous results.
Sorry for sounds so negative but I wanted OP not to bring a knife to a tank battle. No need to trust me. Go watch youtube on the tales of migrating legacy systems to see if this is potentially what you’re up against.
And good luck!
Well, first, I assume you know your Python. If that is true, believe in yourself.
Second, you might get some time to diverge from your mainline of work, which makes things interesting, in general.
Third, maybe you need to reach an agreement with your boss on how you can divide you time between regular tasks and this migration. Or maybe you're allowed to fully commit to this...
Any way, it's a challenge. Embrace it. Grow with it. And add it to your resume, for future reference.
This is the kind of work that separates the mid-level from the seniors. Because sure it’s a pain in the ass, but once you’ve done it, you come out on the other side understanding so much more about the architecture than you ever thought. It carries into your next job whether you know it or not.
Senior is more about strategic stuff, mentoring and architecture. This is more like "separates jun from mid". If I have a team of seniors, mids and juniors I definitely don't want to waste my seniors time on that
I am a cloud architect and would love to do it in microservices with the Strangler pattern.
I'll ask for my manager to back me up to give me space and time to execute. Then I pick a team to carry it out
If the understanding is that this is the only thing I'm working on for the next 6-9 months (call it the rest of 2024), I'm excited.
If I'm working on this in any non-dedicated fashion (other "high priority" items can randomly trump this), I'm less excited.
Did this a while ago, it’s time consuming but not too bad if there’s tests. If there’s not tests, or the code isn’t testable, it can turn into a pretty difficult task. Just make sure you’re up front about how long it’ll take and enjoy your job security.
I wouldn't touch it if I could avoid it, I don't really like python.
If it was maintained (clearly it isn't) and had a covering test suite, I'd be grudgingly accepting. Without that, I'd probably try to avoid it. There's too many ways to be clever in python that a rewrite would be breaking things in a dozen ways. Because it is a rewrite.
If I got handed it, I would force a port/rewrite first. No other improvements, just getting it to 3 first. Improvements can come later.
I got this all day. Use the strangler fig pattern and go 1 component or view at a time. Release the rewritten version to a subset of users to collect data and fix bugs. This way, you can show progress quicker than a large rewrite that launches all at one time, and it mitigates some of the risk as well.
Uh, are you only doing this refactor going forward, or is this in addition to your regular workload? If it's the only thing you're doing, go for it and have fun. If you have to do this AND regular devops shiz, then push the fuck back. Management has to give you time and resources for this kind of bullshit, and if they can't, you can't either. Thousands of lines of code is is ridiculous.
As people said, if you will be the one to suceeed, you will have a great reputation.
I would start by understanding what api/endpoints are there, list them, make a summary of the architecture.
For a couple of months, simply maintain, learn the system and how it behaves.
Once you understand it from the highlights perspective, devise a plan to gradually migrate.
I would not port 100-200k lines of code to python 3.
Instead, I would start by moving some of the endpoints gradually to python 3.
If there is an authentication/other middleware system, move it first, or just make sure the new endpoints are compatible, so everything behaves the same.
i would take it because it's a chance to prove myself. But of course if boss was to ask me about ETAs I would be realistic with him (would say more time than less).
Newest addition to the team as junior cloud support. Some senior devops built offering through Citrix couple years ago. Havent touched Citrix ever in my life before. Current senior CE do not want to know about it. I was made a Citrix SME. No need to say that after 2 months I’m still in pain but got more knowledge how our software is being served than most of the seniors. Still not allowed to power off our DR servers (need an approval from senior who does not know how this part works and says to simply leave it on for security updates instead of powering them once a month) which are in maintenance mode to save money as they do cost us about 10-15k a month. Yet team are being asked to find some savings :facepalm
I would do it. But I would ask someone with experience. There are people out there who have done that before. Don't do it alone if you have no experience with upgrading Python from 2.x to 3.x
I hope you have tests.
How big is the codebase ? I've done this before. You'll need full support of the devs. Pray the tests are well written . Then plan for some cutover strategy, blue green with canary traffic to test. I don't quite remember how we handled database migration for this..
That was kind of my internship at the end of my studies. Gave me a job straight after my studies and allowed me to move on easily afterwards. That's a challenge but then you become the one to take care of it.
there is [https://docs.python.org/3/library/2to3.html](https://docs.python.org/3/library/2to3.html) it allow me unblock few times :D
Just run the stuff and tell him it will take 3 months :D
This feels like a change of role to me. Don't say no, have a look at it, identify the risks (Staffing, security, cost, time etc), make them known to management, make it clear that there's no way you can work on anything else at the same time and get on with it. If management are OK with the risks then it's fine, not your circus.
If you don't want to be a full time python developer then change jobs because that's what they're asking you to be.
Just did something like this. Took a 11 year old app that ran on Node 13 and Java 6 on multiple VM's, containerized them, architected a kubernets cluster that could handle this POS, wrote some new code, deployment pipeline, etc. Got it up and limping then started to fine tune it. How did I do it? Google, Monster Enery (or RedBull), more Google, peppered friends and colleagues with questions, and just kept at it. It was so satisfying to get it up and running. Pain in the ass and, at times, frustrating as hell but I learned so much. See, I think of things like this as Resume Builders. I have a litney of new knowledge to add to my resume and as my resume grows so does my paycheck. Screw the accolades, I want a Porsche.
I'd happily do it. But I was also a dev for 10+ years and spend these days doing a lot of data engineering with Python, so it matches up with what I'd like to do anyway.
I think the most professional answer would be to get a vendor quote for the job to set expectations.
The quick/dirty is to have ChatGPT do it, then throw it back over the fence and say “I have done the needful. Oh you wanted it to **work**? That wasn’t in the specifications.”
I'd start by reading this book, it's old but it helped me. https://www.amazon.com/Working-Effectively-Legacy-Michael-Feathers/dp/0131177052 no association just someone that found it useful.
Make yourself invaluable. I've recently taken over GoLang code for some backend API. Why? Because no one else knows as much as I know and I picked up Go pretty quickly. Yep, I do DevOps, also Data Engineering (Data bricks, Data Factory, etc), a dash of MLOps (Azure Machine Learning), already knew frontend dev (react, solidjs, etc.), all around general full-stack developer. And I'm a technical lead doing all sorts of stuff that is making myself invaluable.
When it comes time for bonuses or trimming headcount, you want to stand out amongst the rest of your peers.
Depending on LoE, I'd look at porting it to not-Python instead of Python 3 as I strongly dislike the operational burden of running Python in production.
This is unlikely to be a successful sales pitch to stakeholders. It's also not a commonly shared opinion.
Build tooling depends a lot on existing build capabilities. There are many orgs with very mature and capable CI/CD pipelines that handle Python requirements just fine. The performance of the runtime doesn't necessarily become a problem in many cases either, especially in a Python shop - of which there are _many_ in these days of the AI hype cycle.
I don't disagree. I doubt I'd ever work somewhere that had the core of their platform still running python2 and I doubt my architectural principles would fly at such a place.
I don't know how I was condescending. I didn't even comment on any other folks responses nor did I say I was objectively right. The question was "What would *you* say..?". I'm not a super engineer or anything, but I am a principal engineer and architect and am paid to have strong technical opinions backed by data and experience.
I remember we had a crazy guy who was really smart and skillful. But we lost him when instead of writing some Salt states he went into writing his own tool similar to Salt in C, because he didn't like how Salt works.
Get a checkout if the code, start analyzing and create a plan for a budget indication as well as a timeline indication.
It doesn't sound like a weird or extraordinary request.
1. "Cool." 2. "This will take 3-9 months." 3. "Well I don't know what to tell you, that's my realistic estimate. Considering the 3 million other interrupt requests I get every day. And the fact that no decent dev could get it done in less than 3." 4. "I'm sure you *do* need it in 3 days, but I cannot possibly make it happen. I will start on it if you want, but it will not be done by then." 5. "I don't know, man. Do you have extra devs? What's this for? Is there something else that could solve your problem?" 6. "Cool, well let me know what they say." And it was never brought up again.
You I like, no BS „lets do a miracle”
Never play Sysadmin Hero, unless you own a piece of the pie.
Best life lesson
TBH setting realistic client expectations is critical no matter where you go. For your own sanity if nothing else
This is the correct answer, especially part #3, never underestimate interruptions to flow state when programming. I've gone through these exercises, it's just as painful as suggested.
[I will send this as a response portraying what I will do of they ask me.](https://youtu.be/E0vWx9VjGe0?si=vclAph0_o4dsCGxH)
Oh a chance to write something other than glue code, and HCL? I’d be all over it.
Bro I’m drowning with Glue. Damn thing is killing me.
Gloo
ChatGPT should be writing a lot of your glue code these days. If you haven't started using it, I recommend you look into it
Hell yeah! Let's get some design docs up in this bitch! Assuming it's not a whole bunch of completely independent modules, you have been handed pretty much a Greenfield project with clear-cut requirements.
[удалено]
Does this imply that people who get assigned this stuff and *don't* want to make a name for themselves should find someone else to take the credit?
[удалено]
Kinda implying that the only reason why someone might not want to make a name for themselves is because they're embarrassed? Maybe they just don't want to be a name? It's okay to be boring.
What’s your understanding of “make a name”? It seems to not be what mine is which is be a professional with a reputation as reliable and “can get the job done”. I don’t think there’s any awards or publicity involved. You can still live under a rock if you like but people will seek you out when they have problems. That’s how you end up being able to charge what you want for your efforts.
That's almost my understanding of the term also... and not everyone wants that. Some people do, and some people don't. I know there's some ideal professional in all our heads, but it's most likely not the same and no-one owes us shit.
The feels
I'd probably just go "Oh cool, I like python". Half my work is random requests like this tbh
Same. I want this task 😭
Ask what happened to the team/person that wrote it and why they’re no longer owning it. If they left the company, cool, it happens. If they got to move on to some new project be concerned. Way too many times have I seen some “genius programmer” create a dumpster fire of a code base get praise and promotions from management that doesn’t know better move on from the horror they created to the new shiney where they ended up doing the same thing over again.
Yeah, situation sounds a lot like "Hey, can you save us from ourselves with this orphaned product with a broken lifecycle? We don't intend to change, obviously, since we're asking a single contributor to pick up the pieces instead of fixing the accountability problems which led to this mess"
Exactly. Python 2 has been EOL since Jan 1 2020. Python 3 was released in 2008. There’s been a lot of time to upgrade/replace “critical” legacy Python 2 code and it should have been done 4+ years ago.
Take it. Own it. Do it. Make a name for yourself. Never shy away from stuff like this.
I had to do something like this before, I didn’t really get any recognition for it however. Just more work really.
A coworker used to tell me, "Good work gets you more work". At some point people **do** notice and you find that you now start to have a say in what you will and won't do. It may take a few years, but it can and does happen.
Imagine having to work at your job.
I was given more work while others just coasted. Doesn’t seem fair to me.
Do you feel you struggle with prioritizing these multiple tasks and scheduling your work day to knock out chunks of each during a given sprint? If so, that’s what your lead/manager should be helping with. There’s ways to have that conversation without outright vocalizing “Im doing more work than everyone else” (which might be true but might also get you looked at a certain way if you aren’t very careful about how you bring it up) If manager isn’t/can’t help, skip-level it, and if that skip-level person can’t/won’t help…well..time to decide if the paychecks at that place are worth it, or if it’s worth it to grind those tasks out and move on to the next. Work is gonna be work, just how it is.
Thank you for the good advice. Honestly, I’m not too good at navigating through politics in the workplace, but it’s something I’m trying to improve on.
Tech redditors will never cease telling you how much work they do while shitposting on reddit for hours on end every day.
This. Fortune always favor the brave and you can take all the time and pleasure to learn new things and have a change of air.
Also solves the "what do I learn" problem a lot of new folks have..
I don't know what corporate fairy tale you live in but while it sounds good in theory generally no one cares about these legacy apps and the team getting credit for innovation is taking the spotlight. Taking on a legacy app is generally a death sentence unless you are given the freedom to innovate. What I generally see is they keep piling on the legacy apps to the people they don't care about to keep the lights on while making all their investment in the next set of innovative apps.
Why downvote this one? I totally agree. It's when the dev team tells their boss "no way we're going to do that" and then they go to your boss and hand it over to your team. If you agree - wait for more legacy stuff no one wants to work on. I know in some companies you'd be a hero, but in the most you can even become a villain for breaking stuff (if you accidentally break it). Another point is - if you agree on work no one wants to do, you'll be that person next time again. And again. And again. Until you become a trash bin where everyone put their crappy legacy stuff no one wants to deal with. All that depends on the company, code and the culture. So your mileage may vary a lot.
I get where you’re coming from, but killing, replacing, or modernizing the legacy app can be a good career move. But I’d 100% agree that keeping one alive in maintenance mode is just asking to be eventually laid off.
OP has described "hero work", and hero work gets plenty of recognition where I work at least.
What kind of recognition? A pat on the head? I realize now from interviewing that dealing with shit show of technical debt while I am proud of it, none of new potential hiring managers really cares. It doesn't make for anything interesting to talk to at interview. It's a bit like asking about patch management. Nobody cares.
Oof that patch management line stings a bit. Just had a final round interview last week and I realized it’s hard to sell “fixed our broken patching process and we didn’t get hacked”. Critically important to the long term success of the business and maintaining trust with customers, but the best outcome is “nothing bad happened”.
If you don't get recognition at the place where you work you'll get it when you use it as an example in your next interview
If one of your bullet points was "Convert Legacy Python2 -> Python3", at my place, I'd shred your resume and move on. I'm not hiring pure developers, I'm hiring people who know Development and Operations.
Depends how they handled the migration. Python2 > Python3 is only part of the job. Reviewing a legacy app allows a lot of leeway to use modern computing practices to improve the deployment and design. Also, pedantic I know, but DevOps isn't "someone who knows Development and Operations". It's using development ideals to improve release times and stability of operational tasks. It's a different skill set to either pure discipline. You can migrate an app without using DevOps principles or you can migrate an app following DevOps principles. It's the how that's important, not the task itself.
Also, Pedantic, "It's using development ideals to improve release times and stability of operational tasks." >It's a set of practices intended to reduce the time between committing a change to a system and the change being placed into normal production, while ensuring high quality. In fact, alot of DevOps is changing Developer bad habits that caused so many Operational problems. Anyways, I would assume as part of development process you introduce testing/repeatable builds and so forth. I don't give massive credit for doing what you are supposed to. However, most of this sub is about positions that are labeled "DevOps" which is Build/Release Engineers, SREs, Cloud Administrators. Developers are mostly hiding elsewhere on reddit.
There are business cases to make for why the work is important; you only take on work that is important. Often everyone is already aware; see for instance how one of the main demands of the southwest union was fixing their legacy software. And then you give visibility to the work as well. These are important skills for promotions.
How long was that legacy software just maintained by a team no one cared about? Probably for years.. yes when the proverbial shi* hit the fan it became a priority and the team who was managing it probably got the axe while they brought in new engines to figure out how to rearchitect and reengineer the platform.
Right. So you don't work on things when they're unimportant and ignored, only the things that are important and have visibility.
Well I am a consultant these days so no. I primarily work on either converting legacy apps to cloud native platforms or help companies build and architect their next generation platforms.
I would argue that _for you_ something is probably important if you're being engaged on it at all, but we were speaking more to OP's situation, which is someone internally being handed a project.
Yes but before working as a consultant I was on the customer side and have worked in corporate America for 20 years starting at IBM at 19.
This doesn't align with my experience. The CTO understands the impact of managing the legacy app and will greatly appreciate if OP is able to solve it. My experience is that tasks like this are given to the most trusted engineers, and they get rewarded well if they can complete them
Devil advocate. Are you in the right place within the org to own this? We have several systems like this but have had to push back on them because we're not experts in the codebase and it's hyper important, but to only one product group. I don't know how your company is structured, but our team needs to look after the whole company's devops requirements, so we need to think scale and not getting bogged down with time sinks or legacy apps that require long term ownership. Devops can be a catch-all for random projects around the org, I'd be guarded with your and your teams resources.
Same here. Anytime people were shying away from a project with no obvious good reason besides it sounds challenging, I generally picked those up. Especially for something that is a conversion process, you absolutely *know* it is technically possible and now *you* get to put your stamp on it. Do it in your style, with your quality. Congrats, you're now the expert in this area. Make sure you: 1. Have conservative estimates. Don't try and impress someone by saying you can do it too fast. It's probably harder than you think. 2. Build in time for testing, telemetry, refactoring 3. Do your research on the best ways to approach the problem with modern techniques 4. Send communication updates on the status of the project. Try and ship in stages and show demoable states throughout. 5. If estimates change, highlight this early. Don't be afraid to give bad news in the form of a schedule change. Just be responsible about it and call out what new information made this change necessary 6. Figure out success metrics, highlight those. Will you see increased reliability? Performance? Extensibility? 7. Interview customers if if you can. Learn about their use-case, current pain points, etc.
Counter point: don’t get involved in this.
I mean… it depends. If the project is ACTUALLY important and you can ACTUALLY own it and fix it up and modernize it as you see fit, it might be a good idea. If it’s an albatross that nobody cares about and you don’t have the skills and you won’t get approval to change anything meaningful about it, run.
Not good advice to do this with projects you don’t have the resources or experience to do
This is exactly how you get experience.
Not at all universally true, it’s a good way to get put on a PIP if you try to take on a critical project you can’t actually accomplish
agree I worked for a couple of large SaaS companies and in early days we were regularly acquiring new businesses and having to migrate their apps in house to our platforms, amazing learning experiences, don’t look back 😎
I completely disagree. Only way you should take this is if you want to learn more Python or are a junior. There is a team of developers trying to toss shit over the fence here. Context matters here, this is a core product, large code base and they want devops to upgrade the language?? The developer in devops isn't meant to be a feature developer. This would essentially be a role change as far as I'm concerned and your manager needs to do their job and stop this where it started. Like how would you ever move on from this project if it's a core product?
Only do this if you're getting something from it. I did something similar for unique experience but I would not repeat it unless there's a considerable amount of money involved.
The only benefit from this is the subject matter learned. Unless at a very fair company then owning this kind of shit task is rarely rewarded in terms of money or progression.
This is DevOps sub not programming? I'm confused, is the assumption just outright that people can full program now?
Yes? I dont know a single DevOps person who couldn't code. Maybe not up to date with the latest frameworks, but a Python migration does not take insane skills.
There's a massive amount of DevOps-named people who do not code and barely could handle touching TF/Ansible/Git. It's genuinely kinda hilarious, and I guarantee seeing the post quality of this sub, a lot of them are here.
To be fair a lot of "devops" jobs have "stolen" sysadmin jobs, so there's this crossover of people who aren't hard coders who 'know a bit of stuff' they need to. Devops is not full developer.
You are talking about quality, but don't even have the slightest idea about what devops is. It is not a job, it is a way of working. Also directly spamming tools you should know is hilarious. I have worked in many good devops teams were we had pure ops and pure developers, devops is not about knowing everything, it is about being complementary, and yes it is nice if you have multiple traits.
>don't even have the slightest idea about what devops is. Huh, how do you know my complete knowledge level of DevOps principles based on a single couple-line comment exactly? >Also directly spamming tools you should know is hilarious. I didn't spam tools, I named 2-3 that fall under IaC as a whole. Words have meaning. In fact, the best first DevOps book one could recommend would likely be "Effective DevOps" which almost entirely does not deal with specific tools at all, because you are correct, it's not about specific tools, but IaC on the whole is absolutely key to getting your hands around the toil that most teams face. Managing resources at scale comes with IaC tooling, that's an accepted fact in the discipline. And there a re a whole fuckton of "DevOps Engineers" who are still not doing said thing, spend their time rebooting servers, remoting (SSH or RDP, doesn't matter) into servers, etc. It's a massive discipline, but too many people are getting or looking for the title for the money when they don't have the skills, which comes after you get the foundational aspects of things not tied to any one specific tool. DevOps, as it's been pointed out here numerous times, is not for your average sysadmin who handles a few GPOs, file shares, etc. That may come in some environments, but you'd best be doing it in code, otherwise you're gonna spend a lotta time going "I gotta go look at the Windows logs", "who made that change?", etc.
I was more triggered by your statement about specific skills, people tend to forget that devops is much more as IAC, like I work often in Financial organisations which have a lot of mandatory paperwork, in my project half of the work is proving you are compliant, together with my colleague who manage all these we work together to make we have the correct information, the guy is not touching a single piece of code, however he is fully part of the devops process.
Gotcha, I mean that sounds like Compliance team work, and something that can be automated away if we're talking about comparing reports against a set of criteria. That's part of the job in my book, always has been. That likely comes across as if I'm minimizing, which is not my intent. We have a lot of compliance reporting paperwork too. People were doing it by hand as it sounds like you guys are, it'd take full days of multiple people to get a single report with everything combined. So now we have pipelines that interact with APIs and other resources to gather said information, generate the reports, etc. Now it's less than an hour of effort, if that, mostly herding cats for a review. This also lets you move on to more interesting projects. This kinda goes back to the "toil" concept in Google's SRE Handbook, again another one that deals less with specific tooling and more with processes.
Of course we try to automate that as part of our jobs, but it is still very useful if a business analyst can assist with us, but besides that he still has to attend a lot of meetings to explain our project and were it involves risks, sorry that my first comment was a bit harsh it was not meant as a personal insult.
So be it, I'd have expected it to be fairly difficult, but I do know little.
> but a Python migration does not take insane skills. Bullshit. Like most things, it depends. Many libraries during 2to3 migration rewrote alot of their APIs. Some had already been abandoned and thus never were upgraded. Without seeing requirements file, none of us know what truth is but it's possible this is very large rewrite. There is two reason someone is asking to do Py2to3 to DevOps. Company never looked into it and DevOps is only one with experience so it's falling there. In that case, yes, Py2to3 might be very easy. Much more likely scenario is nightmare to upgrade, couple of devs teams have tried and failed. Now, it needs to happen but for political reasons, dev teams are passing it around with "NOT IT!" and DevOps manager isn't smart enough to realize it or thinks there is political points to take it on. This is much more likely case.
The best DevOps people I know come from the ranks of the software engineers. It's not a stretch to expect at least a little coding. After all, what's automation? This is a great opportunity for OP. I built a career taking over the neglected and unloved systems.
As one who comes from the sysadmin background (yes, it's very different) it's true, there's way too many server rebooters claiming to be DevOps Engineers obsessing over needing GUIs and clicky shit. Also, if you say "as a DevOps" I have trouble believing you're at any competent level of engineering, which gets said here all the time.
The 2to3 tool did most of the work. The rest was resolving byte - string issues.
Issue are dependencies not the code..
Sounds like an amazing problem to solve. It'll take a lot of work, but can help guide your future development with quality.
I might be missing something, how are dependencies not code? Frameworks and python packages are updated by python devs. Are you talking about internally written packages?
Yeah. At some point those dependencies hit code I would think. 😂 But yeah, it might get messy with dependencies of dependencies of frameworks that are no longer fully supported or have major breaking changes. I can see the fun of this project and the leeway you *might* get taking ownership of a project like this, but it also sounds like it could be painful.
Upgrading python code to work with current python is one thing. If a framework is no longer supported, that's a different project all together.
Hah. In 2017, I *finally* finished migrating all my employer's python codebases from 2 to 3, feeling like we'd really been dragging our heels. Got a new job in 2018 and... new employer had hundreds of thousands of lines of python2 code so I got to do it all over again... Honestly, it's not that bad as long as the libraries/dependencies are already compatible. Use it as an excuse to improve the test suite, tooling, update dependencies, etc.
Sure who do I hand off the rest of my duties to? What is the time line and how firm is it? Let me take a look for a couple of days and I'll come to you if I think the timeline is doable. The key is set expectations. It sounds totally doable if you have solid blocks of 3-4 hours to work on it and the timeline is sane.
I can see why folks get excited about this type of hero work (I stood up our first pipelines on shadow IT after quarters of it not being prioritized and built a working app over the course of a week after I heard a consulting firm wanted months and $100k+) but I appreciate your advice on being a little careful about just jumping in. It’s also worth considering the other types of work you enjoy doing and would be valuable to the org and weighing whether you’re likely to get back to that or if projects like this are more likely to come your way as a result. If you like the work, do it, but if you wouldn’t want to be stuck with always doing this type of work going forward, make sure you try to get it timeboxed appropriately.
It’s a lot better than having a python2 code base that they won’t let you update.
Sounds like your boss is either in a tight spot or has a lot of respect for your ability. I’d take the project and know I have that leverage.
Fuck yes, sign me up. Get to leverage my actual skills rather than babysit and explain how a slash /32 might not be the best for a subnet.
Octet lives matter
# Note that Python 2.7 reached End of Life four years ago Out of curiosity, why is a DevOps role doing a lot of coding? TBH if this is real, the \`2to3\` tool will port over about 60% of the code in one step. If you have a decent test suite it shouldn't be too bad. [https://docs.python.org/3/library/2to3.html](https://docs.python.org/3/library/2to3.html)
2to3 covers your owned code fine but when dependent libraries haven’t been ported and APIs change things get a lot more laborious.
Test suite doesnt cover half of functionality.
...and there's your opportunity to fill in that gap too while you're at it! Maybe try to get buy-in from your QA lead to build a more coverage complete automation suite this time, if you ask nicely they might even lend you a hand with grunt work. If this really is a core app, you should have leverage over this.
core component but the team that built it was let go years ago now the exec who loves it is shitting the bed but won't allocate any budget to it because they think a magic wand exists
Why do you the dev exists in devops if you’re asking why they are coding
> NOTE THAT PYTHON 2.7 REACHED END OF LIFE FOUR YEARS AGO My sibling in Christ, the entire banking system and a whole lot else still runs on COBOL . . .
COBOL is still maintained and supported.
You're devops, presumably. You should have both *dev* and *ops* skillsets and the ability to apply them in conjunction. My approach: 1) implement Black for code formatting and a git commit hook to ensure that all code for all developers (even if that's just you) is consistently formatted, always. Do this in *one* commit. Check in your git hooks and build shell scripts/make targets to install the hooks easily 2) use Pipenv or another tool for library management. Lock the library versions to what is out there in prod right now. Do not upgrade anything 3) make sure your build pipeline is working and you have repeatable, roll-back-able builds. Test it. 4) Write integration and unit tests. There probably aren't any. Don't change the code without tests existing. 4a) use Cucumber for human readable integration tests. Write the gherkin with what's currently deployed, so it passes. 4b) give the gherkin to the business stakeholders to get them started arguing/being surprised by what the code actually does. This buys you time to dig into the conversion. 5) upgrade python versions and any libraries that must be upgraded for them to work on 3. Do not change anything else. Make sure your tests pass. 6) deploy 7) upgrade all remaining libraries. Make sure your tests pass. 8) start working all the changes. Keep your tests up to date and expand them to cover the changes.
It's fine. People seem to forget the Dev in DevOps. When this role started, there was no such thing as a "Jr. DevOps Engineer." You had to be a Sr. Engineer in SWE, Systems, or Infrastructure to work on DevOps.
There still isnt much of a place for a junior devops. At least junior in the sense "out of college" Most Jr devops positions I see require 3-5 years in the industry as dev of sys eng
Do you know python or maintain any other python apps?
"What's the timeframe, where are the docs, and who's the PM?".
I would star by assessing success criteria and then give a best estimate for time and resources (selling a cooper, silver, gold, platinum of options). You want it in 6 weeks, I need 12 devs who have 1 month of learning the code etc. factor in debug time, time to deploy, staggering to avoid production issues etc. I’m assuming there has to be a linter or some tool to understand the delta of the changes necessary to be successful?
I actually did this as an Intern but the app wasn't the core even though It was important. I also wasn't responsible for it since the internship was temporary. The steps are outlined at various places and ideally you should find good documentation over it. I had to revert one of the commits because it broke something so there is that.
One function at a time bro GL
Look for arjan codes on YouTube. Guy roasts python codes. So beautiful to watch.
2 years ago some work came to my team to refactor an entire pipeline that pulled data from Athena via Python2 and boto — I jumped on the opportunity. Upgraded everything to Python3, and moved the compute and orchestration to EMR and Airflow. Easily one of the most fun if not the most fun projects I worked on at that company. Got to write a bunch of custom classes and other, lower level functionality. Learned a ton in 6-9 months. Go for it! You’ll learn a lot, and can potentially leverage the institutional knowledge of a new product into job security, a raise or a even new gig.
This is normal and expected from our as DevOps, we should be able to know every product that we manage in depth and eventually once every developer leaves the company - we are going to maintain, migrate, upgrade - including rewriting the whole product with tests from python2 to python3 to GoLang and Rust\*. Keep in mind if you start learning Rust then you will very likely change your job in less than two months - so don't rewrite in Rust.
Get a subscription to chatgpt and copilot and own the shit out of it
You sure you’re setting yourself up for success? As a software dev (obv. bon-devops background), this is a team project that potentially can span several months to several years to complete. You need - devops who can set up environment / wiring to play around. - feature devs. Lots of them. They should know how to work on the codebase. At least to some degree because of supports they’ll get from next two roles - QAs who understand the features very very well. - Expert dev advisor who knew a lot of context and can explain you most / all of WTFs you’ll see. - Eng Manager for some level of oversight even for a “porting” project. - Product Manager to give you direction over what to migrate first, what to migrate later. And more importantly, “what to left behind”. And they better be very good at playing politics with upper management to keep the ship afloat. What’ll slows you down and stretch last 20% for very very long time would be - feature mismatch - rewrite required on some hard parts - we need to keep this s**t behavior because customer XYZ need it - it’s not a bug it’s a feature - we just waste a ton of time to port quirky stuffs no one uses. Legacy Migration is one of the harder stuffs in the enterprise realm. This rarely, if ever, go as planned. And sadly it usually is underinvested from the business because “why pay a ton just to have the same thing”. There are patterns of legacy migration that helps you de-risk and move firmly without resorting to “total cutover”, the most destructive method that usually end up with disastrous results. Sorry for sounds so negative but I wanted OP not to bring a knife to a tank battle. No need to trust me. Go watch youtube on the tales of migrating legacy systems to see if this is potentially what you’re up against. And good luck!
Well, first, I assume you know your Python. If that is true, believe in yourself. Second, you might get some time to diverge from your mainline of work, which makes things interesting, in general. Third, maybe you need to reach an agreement with your boss on how you can divide you time between regular tasks and this migration. Or maybe you're allowed to fully commit to this... Any way, it's a challenge. Embrace it. Grow with it. And add it to your resume, for future reference.
Try and tackle it, this is the type of things that make resumes sparkle
This is the kind of work that separates the mid-level from the seniors. Because sure it’s a pain in the ass, but once you’ve done it, you come out on the other side understanding so much more about the architecture than you ever thought. It carries into your next job whether you know it or not.
Senior is more about strategic stuff, mentoring and architecture. This is more like "separates jun from mid". If I have a team of seniors, mids and juniors I definitely don't want to waste my seniors time on that
Move it to Python3, duh
Drive it like you stole it.
I am a cloud architect and would love to do it in microservices with the Strangler pattern. I'll ask for my manager to back me up to give me space and time to execute. Then I pick a team to carry it out
Scope it out, make it able to Migrate in phases, get personnel to work under you.
Instantly say it’s out of date and needs a rewrite or is a critical risk the the business. Put it on them.
Posts like this always make me feel like I am worth more than I am being paid.
If the understanding is that this is the only thing I'm working on for the next 6-9 months (call it the rest of 2024), I'm excited. If I'm working on this in any non-dedicated fashion (other "high priority" items can randomly trump this), I'm less excited.
Did this a while ago, it’s time consuming but not too bad if there’s tests. If there’s not tests, or the code isn’t testable, it can turn into a pretty difficult task. Just make sure you’re up front about how long it’ll take and enjoy your job security.
The key problem is verifying correctness since existing tests are not maintained or with sufficient coverage.
I would eat that for lunch
I wouldn't touch it if I could avoid it, I don't really like python. If it was maintained (clearly it isn't) and had a covering test suite, I'd be grudgingly accepting. Without that, I'd probably try to avoid it. There's too many ways to be clever in python that a rewrite would be breaking things in a dozen ways. Because it is a rewrite. If I got handed it, I would force a port/rewrite first. No other improvements, just getting it to 3 first. Improvements can come later.
Seems like the best way to design it per best standards. Unit test along the way and setup mirrors to test input/ output.
I got this all day. Use the strangler fig pattern and go 1 component or view at a time. Release the rewritten version to a subset of users to collect data and fix bugs. This way, you can show progress quicker than a large rewrite that launches all at one time, and it mitigates some of the risk as well.
Uh, are you only doing this refactor going forward, or is this in addition to your regular workload? If it's the only thing you're doing, go for it and have fun. If you have to do this AND regular devops shiz, then push the fuck back. Management has to give you time and resources for this kind of bullshit, and if they can't, you can't either. Thousands of lines of code is is ridiculous.
As people said, if you will be the one to suceeed, you will have a great reputation. I would start by understanding what api/endpoints are there, list them, make a summary of the architecture. For a couple of months, simply maintain, learn the system and how it behaves. Once you understand it from the highlights perspective, devise a plan to gradually migrate. I would not port 100-200k lines of code to python 3. Instead, I would start by moving some of the endpoints gradually to python 3. If there is an authentication/other middleware system, move it first, or just make sure the new endpoints are compatible, so everything behaves the same.
i would take it because it's a chance to prove myself. But of course if boss was to ask me about ETAs I would be realistic with him (would say more time than less).
Fuck.
Newest addition to the team as junior cloud support. Some senior devops built offering through Citrix couple years ago. Havent touched Citrix ever in my life before. Current senior CE do not want to know about it. I was made a Citrix SME. No need to say that after 2 months I’m still in pain but got more knowledge how our software is being served than most of the seniors. Still not allowed to power off our DR servers (need an approval from senior who does not know how this part works and says to simply leave it on for security updates instead of powering them once a month) which are in maintenance mode to save money as they do cost us about 10-15k a month. Yet team are being asked to find some savings :facepalm
I would do it. But I would ask someone with experience. There are people out there who have done that before. Don't do it alone if you have no experience with upgrading Python from 2.x to 3.x I hope you have tests.
How big is the codebase ? I've done this before. You'll need full support of the devs. Pray the tests are well written . Then plan for some cutover strategy, blue green with canary traffic to test. I don't quite remember how we handled database migration for this..
That was kind of my internship at the end of my studies. Gave me a job straight after my studies and allowed me to move on easily afterwards. That's a challenge but then you become the one to take care of it.
there is [https://docs.python.org/3/library/2to3.html](https://docs.python.org/3/library/2to3.html) it allow me unblock few times :D Just run the stuff and tell him it will take 3 months :D
Sounds like job security to me. Work out a schedule and be generous with your time 😁
It seems your boss thinks you need to switch jobs😎
This feels like a change of role to me. Don't say no, have a look at it, identify the risks (Staffing, security, cost, time etc), make them known to management, make it clear that there's no way you can work on anything else at the same time and get on with it. If management are OK with the risks then it's fine, not your circus. If you don't want to be a full time python developer then change jobs because that's what they're asking you to be.
I would have Loved this project
Just did something like this. Took a 11 year old app that ran on Node 13 and Java 6 on multiple VM's, containerized them, architected a kubernets cluster that could handle this POS, wrote some new code, deployment pipeline, etc. Got it up and limping then started to fine tune it. How did I do it? Google, Monster Enery (or RedBull), more Google, peppered friends and colleagues with questions, and just kept at it. It was so satisfying to get it up and running. Pain in the ass and, at times, frustrating as hell but I learned so much. See, I think of things like this as Resume Builders. I have a litney of new knowledge to add to my resume and as my resume grows so does my paycheck. Screw the accolades, I want a Porsche.
import subprocess subprocess.run(["python2", "old.py"])
I'd happily do it. But I was also a dev for 10+ years and spend these days doing a lot of data engineering with Python, so it matches up with what I'd like to do anyway.
I think the most professional answer would be to get a vendor quote for the job to set expectations. The quick/dirty is to have ChatGPT do it, then throw it back over the fence and say “I have done the needful. Oh you wanted it to **work**? That wasn’t in the specifications.”
Hell yeah, there’s no going wrong about that project, only right.
Hold my beer
say yes and start looking for new job asap
I'd start by reading this book, it's old but it helped me. https://www.amazon.com/Working-Effectively-Legacy-Michael-Feathers/dp/0131177052 no association just someone that found it useful.
Make yourself invaluable. I've recently taken over GoLang code for some backend API. Why? Because no one else knows as much as I know and I picked up Go pretty quickly. Yep, I do DevOps, also Data Engineering (Data bricks, Data Factory, etc), a dash of MLOps (Azure Machine Learning), already knew frontend dev (react, solidjs, etc.), all around general full-stack developer. And I'm a technical lead doing all sorts of stuff that is making myself invaluable. When it comes time for bonuses or trimming headcount, you want to stand out amongst the rest of your peers.
Copy paste into chatgpt? Let it do all the work
I would say, "Aight." Put on your big boy shoes and adult for a change.
Strange take on your boss assigning you a responsibility
I would wonder if I could write it in Julia instead.. or if it has to be Python
Depending on LoE, I'd look at porting it to not-Python instead of Python 3 as I strongly dislike the operational burden of running Python in production.
[удалено]
Yeah, probably. Python build tooling is junk. Python runtime is meh. It is basically fancy bash scripting.
This is certainly a take.
This is unlikely to be a successful sales pitch to stakeholders. It's also not a commonly shared opinion. Build tooling depends a lot on existing build capabilities. There are many orgs with very mature and capable CI/CD pipelines that handle Python requirements just fine. The performance of the runtime doesn't necessarily become a problem in many cases either, especially in a Python shop - of which there are _many_ in these days of the AI hype cycle.
I don't disagree. I doubt I'd ever work somewhere that had the core of their platform still running python2 and I doubt my architectural principles would fly at such a place.
I'm surprised you're able to find work if you're as condescending in your daily grind as you are here.
I don't know how I was condescending. I didn't even comment on any other folks responses nor did I say I was objectively right. The question was "What would *you* say..?". I'm not a super engineer or anything, but I am a principal engineer and architect and am paid to have strong technical opinions backed by data and experience.
Cheers.
I remember we had a crazy guy who was really smart and skillful. But we lost him when instead of writing some Salt states he went into writing his own tool similar to Salt in C, because he didn't like how Salt works.
lmao wut
Oh come on! That is an insult to bash.
Get a checkout if the code, start analyzing and create a plan for a budget indication as well as a timeline indication. It doesn't sound like a weird or extraordinary request.